From nobody Thu Aug 1 12:15:49 2019 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF3B120059; Thu, 1 Aug 2019 12:15:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: draft-ietf-opsec-urpf-improvements@ietf.org, opsec-chairs@ietf.org, Sandra Murphy , opsec@ietf.org, sandy@tislabs.com, warren@kumari.net Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156468694278.19363.10253176611678994391.idtracker@ietfa.amsl.com> Date: Thu, 01 Aug 2019 12:15:42 -0700 Archived-At: Subject: [OPSEC] Last Call: (Enhanced Feasible-Path Unicast Reverse Path Filtering) to Best Current Practice X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 19:15:43 -0000 The IESG has received a request from the Operational Security Capabilities for IP Network Infrastructure WG (opsec) to consider the following document: - 'Enhanced Feasible-Path Unicast Reverse Path Filtering' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-08-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document identifies a need for improvement of the unicast Reverse Path Filtering techniques (uRPF) (see BCP 84) for detection and mitigation of source address spoofing (see BCP 38). The strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see BCP 84). However, as shown in this draft, the existing feasible-path uRPF still has shortcomings. This document describes an enhanced feasible-path uRPF technique, which aims to be more flexible (in a meaningful way) about directionality than the feasible-path uRPF. It can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers, and encourage greater deployment of uRPF techniques. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsec-urpf-improvements/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-opsec-urpf-improvements/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc4271: A Border Gateway Protocol 4 (BGP-4) (Draft Standard - IETF stream) From nobody Fri Aug 16 00:11:18 2019 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29E7120118 for ; Fri, 16 Aug 2019 00:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, 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=CCte0l2n; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=oQP8PKyx 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 59njKv8I6LBY for ; Fri, 16 Aug 2019 00:11:13 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A541120112 for ; Fri, 16 Aug 2019 00:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4993; q=dns/txt; s=iport; t=1565939473; x=1567149073; h=from:to:subject:date:message-id:mime-version; bh=wqeR2nfg1GlKVup+j4vqq1CzUINdeMJ6enqLXG9O3xU=; b=CCte0l2nPkBmSDKVJhcm2zyXsrZbdKk9MKvKfQNT0UO2z+3FXDspvo00 XDxHlx96E0/es7K/fcv5kMqQs9NfWhsRZrY1pqGKTlNs4tumNqexhtYrn aTYoFVC2prsANpILD0I/BL3M1L6T0JpjVzYuzZnHHFn2lQfe4c5wo00Tu 4=; IronPort-PHdr: =?us-ascii?q?9a23=3AutzsahADp5gRSg5cj1I5UyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs13kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuIeD7aSc5EexJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AQDWVVZd/4gNJK1lHQEBBQEHBQG?= =?us-ascii?q?BVAcBCwGBFS9QA21VIAQLKoQfg0cDindMlRiEWoEugSQDVAkBAQEMAQEtAgE?= =?us-ascii?q?BhFiDASM1CA4CBAEBBAEBAQIBBgRthScBC4VjER0BATgRAQw+AgQwJwQ1gwA?= =?us-ascii?q?BgR1NAx0BAp4GAoE4iGBzgTKCegEBBYJHgkQYghQJgTQBi2gXgUA/gREnH4p?= =?us-ascii?q?ZMoImjxWFDpcxCQKCHZQzG5hCjVeYBwIEAgQFAg4BAQWBUgE1gVhwFWUBgkG?= =?us-ascii?q?CQoNyilNygSmNeQEB?= X-IronPort-AV: E=Sophos;i="5.64,391,1559520000"; d="scan'208,217";a="529833316" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Aug 2019 07:11:12 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x7G7BCKF023565 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 16 Aug 2019 07:11:12 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 16 Aug 2019 02:11:11 -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; Fri, 16 Aug 2019 03:11:10 -0400 Received: from NAM05-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; Fri, 16 Aug 2019 02:11:10 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j8ATvnFCUqfySTvOCGZkC3/s4WxZfMNn2kNm9Dqbqk57kxxkqRaWopc6ETBwQUIOwKCAyZj5cMuQqc+ZfqNzZqAHz3K7VmZmdRF+7EEuM+5iolxWzBY/g2b57g8cV8zpZN0Af/VPcYKVIyU/r4I6wCrX4e7TVTP0Hru9bxjWj2S9UA7ZDWPgx3UfKsVqr4M2Cgqn0CL2Yt8CalqdqCmRKosy/ged8RQsNxnaR9KaCieAk+PIK6lXKCX1YoWC3faQQ/2Hbh9eNITPllxiZqMRWy+q2J2LniuF9UHuelhT4wDleD9u8PJCr/OUwFrLiCXOyTFk74tT1JYRIEzrad1LMw== 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=wqeR2nfg1GlKVup+j4vqq1CzUINdeMJ6enqLXG9O3xU=; b=MLUqJmh3y7B/Kjnbblz6xF0g40jXbDVqqR9fIbMA4xxWUWpBmi2h8WpctGkgwGTCxo0VlKAM9Glwv2XEUxY8sG1mjT5ehdNorUt7pclo2uzX+XA1EBdA2vAyBhpI1R5GSKG2V4EXRuQbaGBzofHWGvbY1G9WS58oDsPB4CqVgDxSEZzjwUCETWdwCuc8JaQHVzwmbDIc62kbtEmlSMLl/E/UAARPXpDLSxItsjPzK9SS73pQu16eF3wquxfjhoIi8un3RZqVVruLDLCbjnxSySkA1n7aezLM6RVRTy9a/9ObqZgF5bgLg3vzPrOtuLXgAIgeMKhvxJ4U57KWc2TNHQ== 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=wqeR2nfg1GlKVup+j4vqq1CzUINdeMJ6enqLXG9O3xU=; b=oQP8PKyxRwKsazC8KZxEB8zBd/I+itkvyd4KUKjuZaMs5jJsCsrzy1lXOpSYoVXNjKwJMwzH/FFm7zIossNu5rljt0vJA92oYxum5EkOWein1KpM8PcaZOnaWSoAELZaHyDK4QtzftKJYA5Ek8Dxsygew0vtp48AuBYFoQa59/s= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB4333.namprd11.prod.outlook.com (10.255.90.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.16; Fri, 16 Aug 2019 07:11:08 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::cc02:dc35:1f73:653c]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::cc02:dc35:1f73:653c%7]) with mapi id 15.20.2157.022; Fri, 16 Aug 2019 07:11:08 +0000 From: "Eric Vyncke (evyncke)" To: "opsec@ietf.org" Thread-Topic: Chairs' & authors' review of draft-ietf-opsec-v6-17 Thread-Index: AQHVVAHGlY/+SOUqz0e0+4XqGGC5SA== Date: Fri, 16 Aug 2019 07:11:08 +0000 Message-ID: <371D6B14-D4C0-47E4-976E-F412EA277394@cisco.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1b.0.190715 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:74c9:ae24:23dc:6a5a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a9aa7f93-3360-4a61-c4c7-08d72218e979 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4333; x-ms-traffictypediagnostic: MN2PR11MB4333: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0131D22242 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(346002)(39860400002)(376002)(136003)(189003)(199004)(14454004)(66556008)(5660300002)(4744005)(256004)(2501003)(8676002)(86362001)(6486002)(7736002)(71200400001)(6916009)(71190400001)(2906002)(5640700003)(58126008)(66946007)(76116006)(66476007)(478600001)(2616005)(25786009)(6436002)(476003)(46003)(53936002)(2351001)(66446008)(36756003)(91956017)(186003)(64756008)(81166006)(81156014)(1730700003)(8936002)(33656002)(99286004)(6306002)(102836004)(316002)(6506007)(6512007)(486006)(54896002)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4333; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: vktkY30828SExaT2weUgBCVoxGQ5A41MbL2Q0/S9IQbf4I97J0hF9xEtefWRVkb+lJG+vwLuIgfaqHRSjvrcnCFMGeuUkBAOuU1zuDINJEvNbNnQpb9dNH1acbb1C6Uusehj8GwuBOOKIfygau/y8Aw1HzgWr9/8ArmgD348hDtViCR3QEkuTpG5DhcFxcDpEqx5r9wAX2jzdXZkuOVu5FQ76o4IZOZmQCtJj65NcIINrdh1ScjEh2ckW7u95G0aXdbIvXSKOX+LtkCKN4XBfnwcIfNYsjzvsNute3eIQyy1mlL9Gw8NWygBjus1bI7ha4mGVHITIo1WhEoamvY1fopc87v1A7YwiO+t55mG4807CionReX6JXpSjvkq+Kej+qxeyp9Lk+aUIUcfFRBUcU3Qmc3hIDKs1OFY0Y550+g= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_371D6B14D4C047E4976EF412EA277394ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a9aa7f93-3360-4a61-c4c7-08d72218e979 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2019 07:11:08.5406 (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: DgMqhHW0wgUF/hgGX53towu/NdmBtZt7t/dwmzDFbeqMOl/AGenRWOok7rK82JBVamkDY7OTgu0IaIpsmN6/+w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4333 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.30, xch-aln-020.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: [OPSEC] Chairs' & authors' review of draft-ietf-opsec-v6-17 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 07:11:16 -0000 --_000_371D6B14D4C047E4976EF412EA277394ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmVuIGFuZCBSb24sDQpBcyBkaXNjdXNzZWQgZHVyaW5nIHRoZSBJRVRGLTEwNSB3ZWVrLCB0aGUg MyBvZiB1cyBzaG91bGQgcmV2aWV3IHRoZSBkb2N1bWVudCBiZWZvcmUgZ29pbmcgV0dMQyBhbmQg d2Ugc2hvdWxkIGFwcGx5IGR1ZSBkaWxpZ2VuY2UgdG8gdGhpcyByZXZpZXc6IDEgZmlyc3Qgb2Yg QXVndXN0LiBGWUkgSSBoYXZlIHJldmlld2VkIGRyYWZ0LWlldGYtb3BzZWMtdjYtMTcgY29tcGxl dGVseSBhbmQgSSBhbSBmaW5lIHdpdGggdGhlIGN1cnJlbnQgY29udGVudC4gKGp1c3QgYSBjb3Vw bGUgb2YgdHlwb3MgdGhhdCBJIHdpbGwgZml4IGJlZm9yZSBnb2luZyBXR0xDIHRvZ2V0aGVyIHdp dGggQmVybmllIFZvbHrigJlzIHJldmlldyBhbmQgY29tbWVudHMgZnJvbSBMb3JlbnpvIGFuZCBK b3JkaSkuDQpXb3VsZCB5b3UgbWluZCBzaGFyaW5nIHlvdXIgb3duIHJldmlldyBiZWZvcmUgZ29p bmcgV0dMQz8NClRoYW5rIHlvdSBCVFcgZm9yIHRoZSB5b3VyIHZhbHVhYmxlIHRpbWUgc3BlbnQg b24gdGhlIHJldmlldw0KUmVnYXJkcw0KLcOpcmljDQoNCg== --_000_371D6B14D4C047E4976EF412EA277394ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+SmVuIGFuZCBSb24sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5BcyBkaXNjdXNzZWQgZHVyaW5nIHRoZSBJRVRGLTEwNSB3ZWVrLCB0aGUgMyBv ZiB1cyBzaG91bGQgcmV2aWV3IHRoZSBkb2N1bWVudCBiZWZvcmUgZ29pbmcgV0dMQyBhbmQgd2Ug c2hvdWxkIGFwcGx5IGR1ZSBkaWxpZ2VuY2UgdG8gdGhpcyByZXZpZXc6IDEgZmlyc3Qgb2YgQXVn dXN0LiBGWUkgSSBoYXZlIHJldmlld2VkIGRyYWZ0LWlldGYtb3BzZWMtdjYtMTcNCiBjb21wbGV0 ZWx5IGFuZCBJIGFtIGZpbmUgd2l0aCB0aGUgY3VycmVudCBjb250ZW50LiAoanVzdCBhIGNvdXBs ZSBvZiB0eXBvcyB0aGF0IEkgd2lsbCBmaXggYmVmb3JlIGdvaW5nIFdHTEMgdG9nZXRoZXIgd2l0 aCBCZXJuaWUgVm9seuKAmXMgcmV2aWV3IGFuZCBjb21tZW50cyBmcm9tIExvcmVuem8gYW5kIEpv cmRpKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPldvdWxkIHlvdSBtaW5k IHNoYXJpbmcgeW91ciBvd24gcmV2aWV3IGJlZm9yZSBnb2luZyBXR0xDPzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhhbmsgeW91IEJUVyBmb3IgdGhlIHlvdXIgdmFsdWFi bGUgdGltZSBzcGVudCBvbiB0aGUgcmV2aWV3PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4tw6ly aWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_371D6B14D4C047E4976EF412EA277394ciscocom_-- From nobody Fri Aug 16 15:01:45 2019 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37556120018; Fri, 16 Aug 2019 15:01:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana via Datatracker To: "The IESG" Cc: draft-ietf-opsec-urpf-improvements@ietf.org, Sandra Murphy , opsec-chairs@ietf.org, opsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alvaro Retana Message-ID: <156599290421.23877.9763694862590191063.idtracker@ietfa.amsl.com> Date: Fri, 16 Aug 2019 15:01:44 -0700 Archived-At: Subject: [OPSEC] Alvaro Retana's Discuss on draft-ietf-opsec-urpf-improvements-03: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 22:01:44 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-opsec-urpf-improvements-03: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsec-urpf-improvements/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have significant concerns about the recommendation (in §3.7) to use Algorithm A. I think that the considerations to select an Algorithm are not clear and potentially impossible to verify. Also, the selection of Algorithm A creates a vulnerability that could result in legitimate traffic dropped. §3.7 (Summary of Recommendations) says that "if the scenario does not involve complexity...(see Section 3.3, Figure 4), then...Algorithm A...SHOULD be applied on customer interfaces." >From Figure 4, how does the operator of ISP4 know that it is not in a "challenging scenario" (§3.3)? How can ISP4 tell the difference between ISP2 not propagating routes vs it not even being connected to AS1? By definition, each autonomous system can have its own set of policies, which may not be known by any of their upstreams. In short, I find the guidance provided in the document to select an algorithm not clear enough to really be actionable -- specially in a document tagged to be a BCP. Still looking at Figure 4, if the operator of ISP4 uses Algorithm A (because he/she thinks they may not be in a "challenging scenario"), then it opens the door to ISP2 changing its policy so that the uRPF check in ISP4 fails, as shown in Figure 4. IOW, an attacker in ISP2 could stop advertising reachability to some prefixes and cause ISP4 to fail the uRPF check and drop the traffic. The victim in this case could be AS1, whose traffic (through ISP2 to ISP4) was flowing fine and then it stopped. I am balloting DISCUSS because the guidance provided for the selection of an Algorithm is not clear enough to be certain that the selection is the correct one; and the election of Algorithm A creates a vulnerability (as explained in the text) that is not mentioned. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) The implementation of the EFP-uRPF method is expected at a transit AS. However, that AS has no control over what the origin AS and others announce. I find the use of rfc2119 keywords in §3.2 inappropriate because none of the actions are under the control of the AS implementing uRPF and can't be Normatively enforced. (2) §3.5: "Prefixes from registered ROAs and IRR route objects that include ASes in an ISP's customer cone SHOULD be used to augment the appropriate RPF lists." How? Note that the Introduction already sets the stage by saying that "the routes under consideration are assumed to have been vetted based on prefix filtering [RFC7454] and possibly (in the future) origin validation [RFC6811]." If ROAs SHOULD be used (§3.5), why is origin validation only "possibly (in the future)" considered (§1)? Maybe a better statement would be that "routes SHOULD be validated using prefix filtering, origin validation and IRR route objects". (3) How does EFP-uRPF work when multiple border routers are present in the AS, some customer facing and some not (which I assume to be the normal case)? I'm asking because §3.1 describes the method when "prefixes with the same origin AS were received on different interfaces (at border routers)", and the example talks about the Local Adj-RIB-Ins. I think there's a missing explanation of how the routers with the customer-facing interfaces learn about *all* the received routes if the local policy might select a single BGP best route. OTOH, maybe I'm missing something. (4) The document assumes familiarity with terminology such as "customer cone" or "lateral peer", that is not explained anywhere. The average operator will most likely know what those terms mean and how they apply to their network. However, those operators are not the only people reviewing this document. A short explanation or reference would be nice. (5) Please use the rfc8174 template. (6) [For the AD/Shepherd.] I'm assuming that the intent is for this document to be part of BCP 84, is that correct? I'm not sure how to let the RFC Editor know that is the intent, but it should be made clear somewhere. From nobody Sun Aug 18 14:48:19 2019 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A502112013B; Sun, 18 Aug 2019 14:48:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 C7b5RyL678CV; Sun, 18 Aug 2019 14:48:08 -0700 (PDT) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2119.outbound.protection.outlook.com [40.107.89.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32EDB120047; Sun, 18 Aug 2019 14:48:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EyJO4KUs+DAN7xQhyv6NSez2NzlR3Y44tkFKy6jA3Cfs+jcVrsMUHRgdhYdGmqoYEUQS1QusXYMUvp0Y2iL6FmZrv2B4r1Qy3GaoNFJShqmUIhN3g4XO3yaM/DzqK6S1cTnD9KFbu1UTPGEnAb6FWlJrDlw/4Fxy4ZUxX8sxcxLhNvhmHo5rXcKtL51xzv0EUTiUJavLrUjZ99Z3YrhYjlFXfsyVSCuKMYwwFjzLI5w2c6pbRPnFoxCPfMAOYVwkA15uP5IbHCJOjFeV/GQ+zdiDitSG9ZVceQLnBMJ1eif7k8e03fpMuvSwJ8tqV32d1kVyzCrQLLf4WRL5a4zfjA== 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=f4h93bsJ99nZ37Hp9KOcoc1mBgnCrfqZRhbHw5rJ1WY=; b=HSvAWxhYO9P7vPSaJNf/W+KHXJzy4J+D+BRpF4LaDMTEoTyzuw4HYdJIqP/rqx9qlw0Igl50poAMSk+Kvt502t0nWr4GJEwSpKGEAKWNFGcey2g4jhHwmtFtxozKA3l2qUTWjeTo4/WpEIzmwY4uHRGBwhUfSsTfQzWZ1ucOBvRTjGAN0NFP4sgws9RmO7e9byXKSFZUZkgR4FExH7aVTz9aNyvpnnv3NkzUpozdk13CgcmWw3YhLfdXJrPn9LMjqlluOryEoc6CNX89xjSr6eEFAJu12NkpAEWbaQQiSr1Oasj3MHZmHS8uf5B4Zia9AeLJiQ3Ko0ZsH40AWtI+5w== 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=f4h93bsJ99nZ37Hp9KOcoc1mBgnCrfqZRhbHw5rJ1WY=; b=Ug9rY9h+9tApx9k7JBObkB8EgcjFl84G101+JQ/S9E6Dhj0V1wpvtE+XDOBVgQzfmPVd9yoZwZOxm64vGkvKOMVz1bEfdZdTcg4Q47NE6M1bZAYUduItVX9aApos4MEbwm5vmYcTwbfcEaxAehc7ddvu9vhxqP6j7kMrqRlTSiw= Received: from DM6PR09MB3019.namprd09.prod.outlook.com (20.178.2.203) by DM6PR09MB3020.namprd09.prod.outlook.com (20.178.2.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.18; Sun, 18 Aug 2019 21:48:02 +0000 Received: from DM6PR09MB3019.namprd09.prod.outlook.com ([fe80::fc5a:9648:8e8f:7968]) by DM6PR09MB3019.namprd09.prod.outlook.com ([fe80::fc5a:9648:8e8f:7968%6]) with mapi id 15.20.2178.018; Sun, 18 Aug 2019 21:48:02 +0000 From: "Sriram, Kotikalapudi (Fed)" To: The IESG , Alvaro Retana CC: "draft-ietf-opsec-urpf-improvements@ietf.org" , Sandra Murphy , "opsec-chairs@ietf.org" , "opsec@ietf.org" , "Murphy, Sandra" Thread-Topic: Alvaro Retana's Discuss on draft-ietf-opsec-urpf-improvements-03: (with DISCUSS and COMMENT) Thread-Index: AQHVVH41+WK2q56zSkaIVPY4TX30Q6cBbRMZ Date: Sun, 18 Aug 2019 21:48:02 +0000 Message-ID: References: <156599290421.23877.9763694862590191063.idtracker@ietfa.amsl.com> In-Reply-To: <156599290421.23877.9763694862590191063.idtracker@ietfa.amsl.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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.219.117] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4de36717-96ad-49f5-c12d-08d72425beb5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DM6PR09MB3020; x-ms-traffictypediagnostic: DM6PR09MB3020: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01334458E5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(376002)(39850400004)(136003)(346002)(189003)(199004)(51444003)(86362001)(305945005)(66066001)(2906002)(71190400001)(71200400001)(52536014)(5660300002)(256004)(14444005)(5024004)(66574012)(33656002)(6116002)(478600001)(6246003)(3846002)(486006)(53936002)(4326008)(476003)(446003)(11346002)(8936002)(66446008)(64756008)(7696005)(26005)(76176011)(81156014)(55016002)(186003)(102836004)(6436002)(6506007)(99286004)(229853002)(25786009)(74316002)(110136005)(9686003)(14454004)(316002)(7736002)(66946007)(54906003)(91956017)(66476007)(76116006)(66556008)(81166006)(8676002)(87944003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR09MB3020; H:DM6PR09MB3019.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: y7ZNPvUmJHm0nffgpGCM08e3utQBZwRU4d1uG7jhfInfG80+XI/gpnFW+Cra3T6j0yx/0eFlIlWV4FW3ZIr9aY1TBHfiUvGmH3M0uSEMzVJ8xq9caaYuSEA0K54kSnJnhDcUoLmUgty76aILfIeSt6S5dOpQFLwKZB0gv7zWxBDlb/Mt25KLrcnJQ1ae+JyviC4iv3jaREEfDswvCYRrDrtL1/S/M6H00/Gqi2ANUFaLiXzl/iCdWdXhhQTqf03svyxAPecNQlnOGYlvwdiA/BraBiPJBurdF+Gum1Dna8W5hM0NM3NI+S8CbsVaEEF5mR8zvV28alohDbnsSdoKgOsfRm8ea0mpMLVvMbWOC4xlzCCN1rk4zdbkK34Ov36vOWcfH+74m6V1GWBSzru6jHi4z2dF/7myWteN7DmyTSE= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 4de36717-96ad-49f5-c12d-08d72425beb5 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2019 21:48:02.5188 (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: CLTN78CNYz2DRUfaaoNFPiYNHQhVcZRQj8Cndb4VX0R17HxD5nAVPe3h+9GJfEhwX0Ia1EOS9HaNcoq4bqBoUA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR09MB3020 Archived-At: Subject: Re: [OPSEC] Alvaro Retana's Discuss on draft-ietf-opsec-urpf-improvements-03: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 21:48:12 -0000 Alvaro, Thanks very much for your careful review and comments. Please see authors=92 responses inline below. >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >I have significant concerns about the recommendation (in =A73.7) to use Al= gorithm >A. I think that the considerations to select an Algorithm are not clear a= nd >potentially impossible to verify. Also, the selection of Algorithm A crea= tes a >vulnerability that could result in legitimate traffic dropped. > >=A73.7 (Summary of Recommendations) says that "if the scenario does not in= volve >complexity...(see Section 3.3, Figure 4), then...Algorithm A...SHOULD be >applied on customer interfaces." > >From Figure 4, how does the operator of ISP4 know that it is not in a >"challenging scenario" (=A73.3)? How can ISP4 tell the difference between= ISP2 >not propagating routes vs it not even being connected to AS1? By definiti= on, >each autonomous system can have its own set of policies, which may not be = known >by any of their upstreams. In short, I find the guidance provided in the >document to select an algorithm not clear enough to really be actionable -= - >specially in a document tagged to be a BCP. You are asking how does an ISP or AS operator know that they have a scenario in which Algorithm A is applicable.=20 Operators have communications at least with=20 their immediate downstream customers. So, consider this=20 scenario: Operator of AS4 knows (says),=20 =93I have only two direct customers AS2 (ISP2) and AS3 (ISP3). Each of them has assured me that they have customers that are all stub ASes and that these customers do not currently use=20 NO_EXPORT on their announced routes. My direct customers (ISP2 and ISP3) have mechanisms by which=20 they would notify me if this ever changes. They further assure me that they would never=20 deliberately drop their customer routes.=94 This gives the operator of AS4 the knowledge/confidence=20 that Algorithm A is applicable at their AS. It should be emphasized that Algorithm A works=20 in scenarios like the above (customer cone depth is limited=20 to two tiers below the ISP) provided each stub customer=20 does not attach NO_EXPORT on *at least* one prefix announcement out of however many prefixes they announce. (We=92ll add this observation in the draft.) There can be many realistic scenarios like the above that exist at the edges of the Internet. But just one is enough to justify the inclusion of Algorithm A in the recommendations (Sec. 3.7). (Note: uRPF is expected to work best at the edges of the Internet.)=20 Further, the feasible path uRPF (FP-uRPF) is already a BCP (part of BCP 84)= . If an operator deems their scenario fit for use of FP-uRPF, then the EFP-uRPF with Algorithm A is also applicable in that scenario and= =20 performs equally or better (i.e., lower false positive rate for SA invalid)= than FP-uRPF.=20 Of course, the EFP-uRPF works better under less restrictive=20 conditions than required for FP-uRPF as explained in the draft. =20 Of course, according to Section 3.7, if an ISP is uncertain that Algorithm A is applicable in their scenario, then they SHOULD apply Algorit= hm B. We'll be happy to reword the section more carefully if you feel that would help. You may advise us on any specific wording=20 you would like to see added. > >Still looking at Figure 4, if the operator of ISP4 uses Algorithm A (becau= se >he/she thinks they may not be in a "challenging scenario"), then it opens = the >door to ISP2 changing its policy so that the uRPF check in ISP4 fails, as = shown >in Figure 4. IOW, an attacker in ISP2 could stop advertising reachability= to >some prefixes and cause ISP4 to fail the uRPF check and drop the traffic. = The >victim in this case could be AS1, whose traffic (through ISP2 to ISP4) was >flowing fine and then it stopped. There are two observations that are in order here: 1. An ISP would not normally drop its own paying customer=92s=20 routes with malicious intent. 2. It is also hard to envision that ISP2 would attack its upstream ISP4 (in Figure 4) just to disrupt its SAV (uRPF), while that results in=20 absolutely no gain but only causes unreachability for=20 its (ISP2=92s) own customer and self-inflicted loss of revenue/customers. = =20 =20 > >I am balloting DISCUSS because the guidance provided for the selection of = an >Algorithm is not clear enough to be certain that the selection is the corr= ect >one; and the election of Algorithm A creates a vulnerability (as explained= in >the text) that is not mentioned. > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >(1) The implementation of the EFP-uRPF method is expected at a transit AS. >However, that AS has no control over what the origin AS and others announc= e. =20 Please see responses above. >I find the use of rfc2119 keywords in =A73.2 inappropriate because none of= the >actions are under the control of the AS implementing uRPF and can't be >Normatively enforced. > Yes, agree. The use of rfc2119 keywords in not necessary in Section 3.2. The recommendations here are to facilitate feasibility of uRPF and are not about actions performed by the AS implementing EFP-uRPF. =20 >(2) =A73.5: "Prefixes from registered ROAs and IRR route objects that incl= ude >ASes in an ISP's customer cone SHOULD be used to augment the appropriate R= PF >lists." How? Note that the Introduction already sets the stage by saying= that >"the routes under consideration are assumed to have been vetted based on p= refix >filtering [RFC7454] and possibly (in the future) origin validation [RFC681= 1]." >If ROAs SHOULD be used (=A73.5), why is origin validation only "possibly (= in the >future)" considered (=A71)? Maybe a better statement would be that "route= s >SHOULD be validated using prefix filtering, origin validation and IRR rout= e >objects". We agree with your suggested rewording in Section 1. We=92ll use that. What is advised in Section 3.5 regarding ROAs is as follows. In Figure 3, suppose that prefix P4 a ROA with with AS1,=20 and AS4 (ISP4) may not have received a route for P4 (on a given customer in= terface). But AS4 (ISP4) has received (on that customer interface) a route for P1 wit= h=20 the same origin AS (AS1) as in the ROA for P4. Then AS4 (ISP4) should augment its corresponding RPF list with P4 to allow the possibility that AS1 could legitimately announce=20 a route for P4 and potentially use a SA (in a data packet) belonging in P4.= =20 We'll add this explanation in Section 3.5. =20 > >(3) How does EFP-uRPF work when multiple border routers are present in the= AS, >some customer facing and some not (which I assume to be the normal case)? = I'm >asking because =A73.1 describes the method when "prefixes with the same or= igin AS >were received on different interfaces (at border routers)", and the exampl= e >talks about the Local Adj-RIB-Ins. I think there's a missing explanation = of >how the routers with the customer-facing interfaces learn about *all* the >received routes if the local policy might select a single BGP best route. >OTOH, maybe I'm missing something. Yes, we perhaps need to explain this better in the document. It is not that =93customer-facing interfaces learn about *all* the received routes=94 but simply that customer-facing routers=20 must learn at least one route (via iBGP/eBGP) for each prefix=20 originated by an AS (in its customer cone).=94 This is normal in BGP. (There is a little more to it; but that is already well explained=20 in the draft so I=92ll not repeat here.) =20 Considering AS4 (ISP4) in Figure 3, the customer-facing router=20 that is facing AS2 learns at least one route each for P2, P3 via iBGP. That is how it includes P2 and P3 in the RPF list (in addition to P1) for the customer-interface towards AS2 (in Algorithm A). =20 > >(4) The document assumes familiarity with terminology such as "customer co= ne" >or "lateral peer", that is not explained anywhere. The average operator w= ill >most likely know what those terms mean and how they apply to their network= . >However, those operators are not the only people reviewing this document. = A >short explanation or reference would be nice. Will do. Will provide explanation or reference or both. =20 > >(5) Please use the rfc8174 template. Yes, this is already included in my author=92s draft for the next version. > >(6) [For the AD/Shepherd.] I'm assuming that the intent is for this docume= nt to >be part of BCP 84, is that correct? I'm not sure how to let the RFC Edito= r >know that is the intent, but it should be made clear somewhere. I am not sure that =93to be part of BCP 84=94 is the intent. The intent is that this RFC/BCP (to be published) will be=20 a new BCP that updates BCP 84 (RFC 3704).=20 It proposes to recommend the new EFP-uRPF which is=20 an improvement over the FP-uRPF in RFC 3704.=20 We=92ll state that explicitly in the abstract as well as the introduction. The draft header already states =96 =93Updates: RFC3704 (if approved).=94 Thank you once again for the detailed review and comments. Sriram From nobody Mon Aug 19 12:27:02 2019 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA5C12084E; Mon, 19 Aug 2019 12:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hAJY5cgaIHbd; Mon, 19 Aug 2019 12:26:58 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4B46120842; Mon, 19 Aug 2019 12:26:57 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id s15so2989429edx.0; Mon, 19 Aug 2019 12:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=0J8uYd+6zM0LKjSp3yylbTLg69I+oUMXk2mWLOvT9oE=; b=sO/oNFyVMCXdtZhFaHO8XQop052h1C02Co9hEh5uN7xzBjOcn57uYaaSvGsV0DaY+V VU0l0pxTSvFA6zLLRKQnkyTlblz/05Pgt6Eeh28S/spBFpZO0OEEYgS12578lQmGVI1V rxR8iJhpwz2WetxXC23bSUirYtMo8eFZos5yw5NkLbLKB/PddzmEYfQpiSA3dImqQM80 2Vk2c0aH+2AZt7emj3kFQnk/cri7WOpR4VK/Vgww9eCPLzwBzeLf8fCUwtgg9bnAHZak pg61GVb9XpVXJQLn7H+NagpwllsZqIWbQTinlfORLdLjrhClKTzHt1Ey2bj5lctM1/U9 kTwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=0J8uYd+6zM0LKjSp3yylbTLg69I+oUMXk2mWLOvT9oE=; b=MK4RlWR3GP6D+FCDkxC7CCKFXRK/7kLGcoXNNrHFLxEorGvCzHWp20jysBPAhnGimX 1MNl9xCqKqOhAMA2AN+UNWN4w3uCaPENLgjMgXuEvop7MtbOKn+4uQuuHAALr/tL4xLJ JRKbirXUNJxPMLIjdr1uUv02/4TKWj6WCVFsj81nkenllI9NyPzB0sB8zvhw8pw8Zhu5 Li7/UkNMI7S2rfxu1xERbc07IK8IHcMQRkYayv/gKrOocHLsiTAYUjie0TvT1hq46+Eg /42z9F9G6hQdm+DPFBz32ZJ7awDmc22K+mZ0iWtZNokDSRNMC1uT/CYC28A4w9/D9tOa rqHA== X-Gm-Message-State: APjAAAWzTG2iVmuDP6KYpeEIBYkLL1ASinviIvRlkG+hN/oWTiF46q3b tnlizwgj49oQz2Uourm1+qPs02SdUD3VgPv2RYw= X-Google-Smtp-Source: APXvYqzyXwN6sLiKHqT9hQNA1W975WentNduz9mHmfZ1zp1WKDyfxsLUKfa+TNto2Cz4y+q7m4ICmjcYEf3qdP5OglE= X-Received: by 2002:a17:906:e241:: with SMTP id gq1mr22325229ejb.265.1566242816233; Mon, 19 Aug 2019 12:26:56 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 19 Aug 2019 15:26:55 -0400 From: Alvaro Retana In-Reply-To: References: <156599290421.23877.9763694862590191063.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Date: Mon, 19 Aug 2019 15:26:55 -0400 Message-ID: To: "Sriram, Kotikalapudi (Fed)" , The IESG Cc: "opsec-chairs@ietf.org" , Sandra Murphy , "Murphy, Sandra" , "opsec@ietf.org" , "draft-ietf-opsec-urpf-improvements@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b1957605907d5216" Archived-At: Subject: Re: [OPSEC] Alvaro Retana's Discuss on draft-ietf-opsec-urpf-improvements-03: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 19:27:00 -0000 --000000000000b1957605907d5216 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On August 18, 2019 at 5:48:04 PM, Sriram, Kotikalapudi (Fed) ( kotikalapudi.sriram@nist.gov) wrote: Sriram: Hi! >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >I have significant concerns about the recommendation (in =C2=A73.7) to use Algorithm >A. I think that the considerations to select an Algorithm are not clear an= d >potentially impossible to verify. Also, the selection of Algorithm A creates a >vulnerability that could result in legitimate traffic dropped. > >=C2=A73.7 (Summary of Recommendations) says that "if the scenario does not involve >complexity...(see Section 3.3, Figure 4), then...Algorithm A...SHOULD be >applied on customer interfaces." > >From Figure 4, how does the operator of ISP4 know that it is not in a >"challenging scenario" (=C2=A73.3)? How can ISP4 tell the difference betwe= en ISP2 >not propagating routes vs it not even being connected to AS1? By definition, >each autonomous system can have its own set of policies, which may not be known >by any of their upstreams. In short, I find the guidance provided in the >document to select an algorithm not clear enough to really be actionable -= - >specially in a document tagged to be a BCP. You are asking how does an ISP or AS operator know that they have a scenario in which Algorithm A is applicable. Operators have communications at least with their immediate downstream customers. So, consider this scenario: Operator of AS4 knows (says), =E2=80=9CI have only two direct customers AS2 (ISP2) and AS3 (ISP3). Each of them has assured me that they have customers that are all stub ASes and that these customers do not currently use NO_EXPORT on their announced routes. My direct customers (ISP2 and ISP3) have mechanisms by which they would notify me if this ever changes. They further assure me that they would never deliberately drop their customer routes.=E2=80=9D This gives the operator of AS4 the knowledge/confidence that Algorithm A is applicable at their AS. Precisely the fact that transitive assurances can=E2=80=99t be trusted abou= t networks being well behaved is that mechanisms like ingress filtering, uRPF, RPKI/Origin Validation, BGPSec, etc=E2=80=A6have been developed. I= =E2=80=99m sorry, but it sounds ingenuous for the guidance to be to trust your neighbors=E2= =80=A6 Quoting from rfc3704: =E2=80=9C...essentially trusts the downstream network= to behave itself, which is not the wisest course of action." It should be emphasized that Algorithm A works in scenarios like the above (customer cone depth is limited to two tiers below the ISP) provided each stub customer does not attach NO_EXPORT on *at least* one prefix announcement out of however many prefixes they announce. (We=E2=80=99ll add this observation in the draft.) There can be many realistic scenarios like the above that exist at the edges of the Internet. But just one is enough to justify the inclusion of Algorithm A in the recommendations (Sec. 3.7). (Note: uRPF is expected to work best at the edges of the Internet.) Further, the feasible path uRPF (FP-uRPF) is already a BCP (part of BCP 84)= . If an operator deems their scenario fit for use of FP-uRPF, then the EFP-uRPF with Algorithm A is also applicable in that scenario and performs equally or better (i.e., lower false positive rate for SA invalid) than FP-uRPF. Of course, the EFP-uRPF works better under less restrictive conditions than required for FP-uRPF as explained in the draft. I couldn=E2=80=99t find much in terms of guidance in rfc3704 about when usi= ng FP-uRPF is recommended, except for this: "Feasible Path RPF=E2=80=A6is suit= able in all the scenarios where Strict RPF is, but multihomed or asymmetric scenarios in particular. However, one must remember that Feasible RPF assumes the consistent origination and propagation of routing information to work; the implications of this must be understood especially if a prefix advertisement passes through third parties.=E2=80=9D I think that the guidance in rfc3704 is about the same as the guidance in this document, plus the fact that some of the potential issues with trusting other networks are at least mentioned there. However, I don=E2=80= =99t think that there=E2=80=99s enough guidance in rfc3704 for this document to = simply point at it =E2=80=94 the same questions would apply: how would an operator= know that "consistent origination and propagation of routing information=E2=80= =9D is present? Of course, according to Section 3.7, if an ISP is uncertain that Algorithm A is applicable in their scenario, then they SHOULD apply Algorithm B. True, but that still doesn=E2=80=99t provide any tools for the ISP to know = either way. If there=E2=80=99s no way to know (other than trusting your neighbors= ) that the network is not in the middle of a =E2=80=9Cchallenging scenario=E2=80= =9D, then why wouldn't Algorithm B always be used? We'll be happy to reword the section more carefully if you feel that would help. You may advise us on any specific wording you would like to see added. > >Still looking at Figure 4, if the operator of ISP4 uses Algorithm A (because >he/she thinks they may not be in a "challenging scenario"), then it opens the >door to ISP2 changing its policy so that the uRPF check in ISP4 fails, as shown >in Figure 4. IOW, an attacker in ISP2 could stop advertising reachability to >some prefixes and cause ISP4 to fail the uRPF check and drop the traffic. The >victim in this case could be AS1, whose traffic (through ISP2 to ISP4) was >flowing fine and then it stopped. There are two observations that are in order here: 1. An ISP would not normally drop its own paying customer=E2=80=99s routes with malicious intent. 2. It is also hard to envision that ISP2 would attack its upstream ISP4 (in Figure 4) just to disrupt its SAV (uRPF), while that results in absolutely no gain but only causes unreachability for its (ISP2=E2=80=99s) own customer and self-inflicted loss of revenue/custom= ers. I also doubt that an operator would take actions to harm its own paying customers =E2=80=94 but the routers can be compromised anyway...or the advertisement can come from the customer itself with a NO_EXPORT community, etc.. The main case I=E2=80=99m thinking of is the compromised/rogue route= r. In any of those cases, choosing Algorithm A opens the door to vulnerabilities. Yes, they might be the same (or at least similar) as what exists with FP-uRPF =E2=80=94 but they are not mentioned. >---------------------------------------------------------------------- >COMMENT: >=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94 ... >ASes in an ISP's customer cone SHOULD be used to augment the appropriate RPF >lists." How? Note that the Introduction already sets the stage by saying that >"the routes under consideration are assumed to have been vetted based on prefix >filtering [RFC7454] and possibly (in the future) origin validation [RFC6811]." >If ROAs SHOULD be used (=C2=A73.5), why is origin validation only "possibl= y (in the >future)" considered (=C2=A71)? Maybe a better statement would be that "rou= tes >SHOULD be validated using prefix filtering, origin validation and IRR rout= e >objects". We agree with your suggested rewording in Section 1. We=E2=80=99ll use that= . What is advised in Section 3.5 regarding ROAs is as follows. In Figure 3, suppose that prefix P4 a ROA with with AS1, and AS4 (ISP4) may not have received a route for P4 (on a given customer interface). But AS4 (ISP4) has received (on that customer interface) a route for P1 wit= h the same origin AS (AS1) as in the ROA for P4. Then AS4 (ISP4) should augment its corresponding RPF list with P4 to allow the possibility that AS1 could legitimately announce a route for P4 and potentially use a SA (in a data packet) belonging in P4. We'll add this explanation in Section 3.5. Hmm=E2=80=A6 Except that the =E2=80=9Cpossibility=E2=80=9D that an announce= ment exists *and* the use as a SA, is different from AS1 really doing it. IOW, augmenting with the expectation that it may happen has its own risks=E2=80=A6 ... > >(6) [For the AD/Shepherd.] I'm assuming that the intent is for this document to >be part of BCP 84, is that correct? I'm not sure how to let the RFC Editor >know that is the intent, but it should be made clear somewhere. I am not sure that =E2=80=9Cto be part of BCP 84=E2=80=9D is the intent. The intent is that this RFC/BCP (to be published) will be a new BCP that updates BCP 84 (RFC 3704). It proposes to recommend the new EFP-uRPF which is an improvement over the FP-uRPF in RFC 3704. We=E2=80=99ll state that explicitly in the abstract as well as the introduc= tion. The draft header already states =E2=80=93 =E2=80=9CUpdates: RFC3704 (if app= roved).=E2=80=9D Updating rfc3704 and being part of the same BCP are separate considerations. To me, the fact that this document Updates rfc3704 makes it a good candidate to be part of the same BCP; a BCP can contain more than one RFC. A good example is BCP 14, which includes rfc2119 and and the more recent rfc8174. Thanks! Alvaro. --000000000000b1957605907d5216 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On August 18, 2019 at 5:48:04 PM, Sriram, Kotika= lapudi (Fed) (kotikalapudi.= sriram@nist.gov) wrote:

Sriram:

Hi= !

=
<= div>>-------------------------------------------------------------------= ---=C2=A0
>DISCUSS:=C2=A0
>---------------------= -------------------------------------------------=C2=A0
>=C2= =A0
>I have significant concerns about the recommendation (in = =C2=A73.7) to use Algorithm=C2=A0
>A. I think that the considerations to select an Algorithm are no= t clear and=C2=A0
>poten= tially impossible to verify. Also, the selection of Algorithm A creates a=C2=A0
>vulnerability that= could result in legitimate traffic dropped.=C2=A0
>=C2=A0
>=C2=A73.7 (Summary of Recommendations) says that "if the s= cenario does not involve=C2=A0=
>complexity...(see Section 3.3, Figure 4), then...Algorithm A...SHOU= LD be=C2=A0
>applied on = customer interfaces."=C2=A0
>=C2=A0
>From F= igure 4, how does the operator of ISP4 know that it is not in a=C2=A0
>"challenging scenario&= quot; (=C2=A73.3)? How can ISP4 tell the difference between ISP2=C2=A0
>not propagating routes vs i= t not even being connected to AS1? By definition,=C2=A0
>each autonomous system can have its own se= t of policies, which may not be known= =C2=A0
>by any of their upstreams. In short, I find the guidan= ce provided in the=C2=A0
&g= t;document to select an algorithm not clear enough to really be actionable = --=C2=A0
>specially in a= document tagged to be a BCP.=C2=A0

You are asking how does an ISP or AS operator know=C2=A0
that they have a scenario in wh= ich Algorithm A is applicable.=C2=A0<= /span>
Operators have communications at least with=C2=A0
their immediate downstream customers. So, = consider this=C2=A0
scenari= o: Operator of AS4 knows (says),=C2= =A0
=E2=80=9CI have only two direct customers AS2 (ISP2) and AS3 = (ISP3).=C2=A0
Each of them = has assured me that they have customers that=C2=A0
are all stub ASes and that these customers do not c= urrently use=C2=A0
NO_EXPOR= T on their announced routes.=C2=A0
My direct customers (ISP2 and ISP3) have mechanisms by which=C2=A0
they would notify me if thi= s ever changes.=C2=A0
They = further assure me that they would never=C2=A0
deliberately drop their customer routes.=E2=80=9D=C2=A0
This gives the operator of = AS4 the knowledge/confidence=C2=A0
that Algorithm A is applicable at their AS.=C2=A0

Precise= ly the fact that transitive assurances can=E2=80=99t be trusted about netwo= rks being well behaved is that mechanisms like ingress filtering, uRPF, RPK= I/Origin Validation, BGPSec, etc=E2=80=A6have been developed.=C2=A0 I=E2=80= =99m sorry, but it sounds=C2=A0ingenuous for the guidance to be to trust yo= ur neighbors=E2=80=A6

Quoting from rfc3704: =E2=80=9C...essentially t= rusts the downstream network to behave itself, which is not the wisest cour= se of action."

It should be emphasized that Algorithm A works=C2=A0
in scenarios like the ab= ove (customer cone depth is limited= =C2=A0
to two tiers below the ISP) provided each stub customer=C2=A0
does not attach NO_EXPO= RT on *at least* one prefix announcement=C2=A0
out of however many prefixes they announce.=C2=A0
(We=E2=80=99ll add this observa= tion in the draft.)=C2=A0
<= br>There can be many realistic scenarios like the above that exist=C2=A0
at the edges of the Internet.= But just one is enough to=C2=A0
justify the inclusion of Algorithm A in the recommendations (Sec. 3.7= ).=C2=A0
(Note: uRPF is exp= ected to work best at the edges of the Internet.)=C2=A0


<= /div>
Further, the feasible path uRPF (FP-uRPF) is already a BCP (part of BCP 8= 4).=C2=A0
If an operator de= ems their scenario fit for use of FP-uRPF,=C2=A0
then the EFP-uRPF with Algorithm A is also applicable= in that scenario and=C2=A0performs equally or better (i.e., lower false positive rate for SA invalid= ) than FP-uRPF.=C2=A0
Of co= urse, the EFP-uRPF works better under less restrictive=C2=A0
conditions than required for FP-uRPF as e= xplained in the draft.=C2=A0=C2=A0

I couldn=E2=80=99t find much in terms of guidance in rfc3704= about when using FP-uRPF is recommended, except for this: "Feasible P= ath RPF=E2=80=A6is suitable in all the scenarios where Strict RPF is, but m= ultihomed or asymmetric scenarios in particular.=C2=A0 However, one must re= member that Feasible RPF assumes the consistent origination and propagation= of routing information to work; the implications of this must be understoo= d especially if a prefix advertisement passes through third parties.=E2=80= =9D =C2=A0

I think that the guidance in rfc3704 is about the same as = the guidance in this document, plus the fact that some of the potential iss= ues with trusting other networks are at least mentioned there.=C2=A0 Howeve= r, I don=E2=80=99t think that there=E2=80=99s enough guidance in rfc3704 fo= r this document to simply point at it =E2=80=94 the same questions would ap= ply: how would an operator know that "consistent origination and propa= gation of routing information=E2=80=9D is present?


=
Of course, ac= cording to Section 3.7, if an ISP is uncertain that=C2=A0
Algorithm A is applicable in their scenario,= then they SHOULD apply Algorithm B.= =C2=A0

True, but that still = doesn=E2=80=99t provide any tools for the ISP to know either way.=C2=A0 If = there=E2=80=99s no way to know (other than trusting your neighbors) that th= e network is not in the middle of a =E2=80=9Cchallenging scenario=E2=80=9D,= then why wouldn't Algorithm B always be used?


=
We'll be = happy to reword the section more carefully if you feel=C2=A0
that would help. You may advise us on any= specific wording=C2=A0
you= would like to see added.=C2=A0

>=C2=A0
>Sti= ll looking at Figure 4, if the operator of ISP4 uses Algorithm A (because=C2=A0
>he/she thinks they= may not be in a "challenging scenario"), then it opens the=C2=A0
>door to ISP2 changing = its policy so that the uRPF check in ISP4 fails, as shown=C2=A0
>in Figure 4. IOW, an attacker in I= SP2 could stop advertising reachability to=C2=A0
>some prefixes and cause ISP4 to fail the uRPF che= ck and drop the traffic. The=C2=A0
>victim in this case could be AS1, whose traffic (through ISP2 t= o ISP4) was=C2=A0
>flowi= ng fine and then it stopped.=C2=A0

There are two observations that are in order here:=C2=A0
1. An ISP would not normally dr= op its own paying customer=E2=80=99s= =C2=A0
routes with malicious intent.=C2=A0
2. It is also hard to envision that ISP2 would at= tack its upstream ISP4=C2=A0(in Figure 4) just to disrupt its SAV (uRPF), while that results in=C2=A0
absolutely no gain but onl= y causes unreachability for=C2=A0
its (ISP2=E2=80=99s) own customer and self-inflicted loss of revenue= /customers.=C2=A0=C2=A0

I also doubt that an operator would take actions to harm its own payi= ng customers =E2=80=94 but the routers can be compromised anyway...or the a= dvertisement can come from the customer itself with a NO_EXPORT community, = etc..=C2=A0 The main case I=E2=80=99m thinking of is the compromised/rogue = router. =C2=A0 =C2=A0In any of those cases, choosing Algorithm A opens the = door to vulnerabilities.=C2=A0 Yes, they might be the same (or at least sim= ilar) as what exists with FP-uRPF =E2=80=94 but they are not mentioned.

=



>-----------------------------------------------= -----------------------=C2=A0<= br>>COMMENT:=C2=A0
>= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=C2=A0=C2=A0

...


>ASes in an ISP's customer cone SHOULD be used to augment th= e appropriate RPF=C2=A0
>= ;lists." How? Note that the Introduction already sets the stage by say= ing that=C2=A0
>"th= e routes under consideration are assumed to have been vetted based on prefi= x=C2=A0
>filtering [RFC7= 454] and possibly (in the future) origin validation [RFC6811]."=C2=A0
>If ROAs SHOULD be used = (=C2=A73.5), why is origin validation only "possibly (in the=C2=A0
>future)" considered (= =C2=A71)? Maybe a better statement would be that "routes=C2=A0
>SHOULD be validated using pref= ix filtering, origin validation and IRR route=C2=A0
>objects".=C2=A0

We agree with your suggested rewording in Sectio= n 1. We=E2=80=99ll use that.=C2=A0
What is advised in Section 3.5 regarding ROAs is as follows.=C2=A0
In Figure 3, suppose that p= refix P4 a ROA with with AS1,=C2=A0
and AS4 (ISP4) may not have received a route for P4 (on a given cu= stomer interface).=C2=A0
Bu= t AS4 (ISP4) has received (on that customer interface) a route for P1 with<= span class=3D"Apple-converted-space">=C2=A0
the same origin AS (A= S1) as in the ROA for P4.=C2=A0
Then AS4 (ISP4) should augment its corresponding RPF list with P4=C2=A0
to allow the possibility = that AS1 could legitimately announce= =C2=A0
a route for P4 and potentially use a SA (in a data packet)= belonging in P4.=C2=A0=C2=A0
We'll add this explanat= ion in Section 3.5.=C2=A0

Hmm=E2=80=A6 Except that the =E2=80=9Cp= ossibility=E2=80=9D that an announcement exists *and* the use as a SA, is d= ifferent from AS1 really doing it.=C2=A0 IOW, augmenting with the expectati= on that it may happen has its own risks=E2=80=A6


...

><= span class=3D"Apple-converted-space">=C2=A0
>(6) [For the AD/S= hepherd.] I'm assuming that the intent is for this document to=C2=A0
>be part of BCP 84, is tha= t correct? I'm not sure how to let the RFC Editor=C2=A0
>know that is the intent, but it should= be made clear somewhere.=C2=A0

I am not sure that =E2=80=9Cto be part of BCP 84=E2=80=9D is the i= ntent.=C2=A0
The intent is = that this RFC/BCP (to be published) will be=C2=A0
a new BCP that updates BCP 84 (RFC 3704).=C2=A0
It proposes to recommend the ne= w EFP-uRPF which is=C2=A0
a= n improvement over the FP-uRPF in RFC 3704.=C2=A0
We=E2=80=99ll state that explicitly in the abstract = as well as the introduction.=C2=A0
The draft header already states =E2=80=93 =E2=80=9CUpdates: RFC3704= (if approved).=E2=80=9D=C2=A0=

Updating rfc3704 and being part of= the same BCP are separate considerations.=C2=A0 To me, the fact that this = document Updates rfc3704 makes it a good candidate to be part of the same B= CP; a BCP can contain more than one RFC.

A good example is BCP 14, wh= ich includes rfc2119 and and the more recent rfc8174.


Than= ks!

Alvaro.

--000000000000b1957605907d5216-- From nobody Mon Aug 19 14:18:09 2019 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0CD1200D8; Mon, 19 Aug 2019 14:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 fIMJMkamxeLr; Mon, 19 Aug 2019 14:18:05 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2733D1200CD; Mon, 19 Aug 2019 14:18:05 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id t50so462042edd.2; Mon, 19 Aug 2019 14:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=KgUMNBWn0ug+xlR0NxRIpRbfQU8RJ5nQEpTPlfqU7dc=; b=RJ0TPUtrLyPa7+PtjdqdSe0bd75lfE5aTclIqz7qYBNsUfUvsn1XRbNHkv3WhVGJ7r iy3gvVkY3vQ/ybk+KRpT7X/OMP4+ac2yFRa5zB+8P2ynedSaPAf6RaeQrVhf1NW/Lzq1 z6WSLFJWvmJWzazo1BDyIL3DycyZPSg4eTkSet6BA5reSOCZUZ/Q2TSP1/N4EBaA6bwQ iGCMWuKzkwHh4ZrU876AQnAS27ZfUx9u4zuPv4BF46veYgh16ORMBe8APBP9E87SE2+0 hrRUZwrC1GIGzkT/trYLZNykS1HquJwO5xJevI42370gszTTZpM1rcTRFLTQ+8l1QSKN pCUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=KgUMNBWn0ug+xlR0NxRIpRbfQU8RJ5nQEpTPlfqU7dc=; b=o460WIAanAlfa3i0fRjpinWo/YrdTHYus3jP8+GjREqkTC9m6mjl+OGJWTmoavFvgN /Kh2/HT5w13+QTFXLv0hc8yO0TGLFiiP0K9K2bElgWYrfqLZmKqb8nOX1DCcezCwdWMX yhbDKYpLn8KByS8NVBbiXQXzjzKy4aP7So8j2oUCnawvz8YgbUYIVtIa7oTSHztRZQ8d X1wyGxxr6PpTanDnn+ybJE3Mw3fuj0Tgnhgj4P/cHH0ghGK7TFvg7nmGSeFBYTTn5pVx HehQuoq7ROv7lRB2RGFmRbZLhdtqAh1VlynpZnNpb1IyrNXLXXk0wT7izgs2DBQrOySt P14Q== X-Gm-Message-State: APjAAAWEFdS3QdBOd6Kj2NV87PBChN57pEi6SD9VWOCcHglVAa6z1BUh HpK+qRL4U8qYVuEvoPKgNWJZaXV5tvGk2Ys8rWM= X-Google-Smtp-Source: APXvYqzdxDhUxS64QlVOdC526Ytkh1li+XadtD91Yw3pLj64Xfj22ol39iaukIXDrABr7FVUBA16fkzjtmdcxXHW17A= X-Received: by 2002:aa7:c498:: with SMTP id m24mr10642118edq.277.1566249483642; Mon, 19 Aug 2019 14:18:03 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 19 Aug 2019 17:18:02 -0400 From: Alvaro Retana In-Reply-To: References: <156599290421.23877.9763694862590191063.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Date: Mon, 19 Aug 2019 17:18:02 -0400 Message-ID: To: "Sriram, Kotikalapudi (Fed)" , The IESG Cc: "opsec-chairs@ietf.org" , Sandra Murphy , "Murphy, Sandra" , "opsec@ietf.org" , "draft-ietf-opsec-urpf-improvements@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001a2a6605907ee014" Archived-At: Subject: Re: [OPSEC] Alvaro Retana's Discuss on draft-ietf-opsec-urpf-improvements-03: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2019 21:18:08 -0000 --0000000000001a2a6605907ee014 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On August 18, 2019 at 5:48:04 PM, Sriram, Kotikalapudi (Fed) ( kotikalapudi.sriram@nist.gov) wrote: Sriram: Hi! >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >I have significant concerns about the recommendation (in =C2=A73.7) to use Algorithm >A. I think that the considerations to select an Algorithm are not clear an= d >potentially impossible to verify. Also, the selection of Algorithm A creates a >vulnerability that could result in legitimate traffic dropped. > >=C2=A73.7 (Summary of Recommendations) says that "if the scenario does not involve >complexity...(see Section 3.3, Figure 4), then...Algorithm A...SHOULD be >applied on customer interfaces." > >From Figure 4, how does the operator of ISP4 know that it is not in a >"challenging scenario" (=C2=A73.3)? How can ISP4 tell the difference betwe= en ISP2 >not propagating routes vs it not even being connected to AS1? By definition, >each autonomous system can have its own set of policies, which may not be known >by any of their upstreams. In short, I find the guidance provided in the >document to select an algorithm not clear enough to really be actionable -= - >specially in a document tagged to be a BCP. You are asking how does an ISP or AS operator know that they have a scenario in which Algorithm A is applicable. Operators have communications at least with their immediate downstream customers. So, consider this scenario: Operator of AS4 knows (says), =E2=80=9CI have only two direct customers AS2 (ISP2) and AS3 (ISP3). Each of them has assured me that they have customers that are all stub ASes and that these customers do not currently use NO_EXPORT on their announced routes. My direct customers (ISP2 and ISP3) have mechanisms by which they would notify me if this ever changes. They further assure me that they would never deliberately drop their customer routes.=E2=80=9D This gives the operator of AS4 the knowledge/confidence that Algorithm A is applicable at their AS. Precisely the fact that transitive assurances can=E2=80=99t be trusted abou= t networks being well behaved is that mechanisms like ingress filtering, uRPF, RPKI/Origin Validation, BGPSec, etc=E2=80=A6have been developed. I= =E2=80=99m sorry, but it sounds ingenuous for the guidance to be to trust your neighbors=E2= =80=A6 Quoting from rfc3704: =E2=80=9C...essentially trusts the downstream network= to behave itself, which is not the wisest course of action." It should be emphasized that Algorithm A works in scenarios like the above (customer cone depth is limited to two tiers below the ISP) provided each stub customer does not attach NO_EXPORT on *at least* one prefix announcement out of however many prefixes they announce. (We=E2=80=99ll add this observation in the draft.) There can be many realistic scenarios like the above that exist at the edges of the Internet. But just one is enough to justify the inclusion of Algorithm A in the recommendations (Sec. 3.7). (Note: uRPF is expected to work best at the edges of the Internet.) Further, the feasible path uRPF (FP-uRPF) is already a BCP (part of BCP 84)= . If an operator deems their scenario fit for use of FP-uRPF, then the EFP-uRPF with Algorithm A is also applicable in that scenario and performs equally or better (i.e., lower false positive rate for SA invalid) than FP-uRPF. Of course, the EFP-uRPF works better under less restrictive conditions than required for FP-uRPF as explained in the draft. I couldn=E2=80=99t find much in terms of guidance in rfc3704 about when usi= ng FP-uRPF is recommended, except for this: "Feasible Path RPF=E2=80=A6is suit= able in all the scenarios where Strict RPF is, but multihomed or asymmetric scenarios in particular. However, one must remember that Feasible RPF assumes the consistent origination and propagation of routing information to work; the implications of this must be understood especially if a prefix advertisement passes through third parties.=E2=80=9D I think that the guidance in rfc3704 is about the same as the guidance in this document, plus the fact that some of the potential issues with trusting other networks are at least mentioned there. However, I don=E2=80= =99t think that there=E2=80=99s enough guidance in rfc3704 for this document to = simply point at it =E2=80=94 the same questions would apply: how would an operator= know that "consistent origination and propagation of routing information=E2=80= =9D is present? Of course, according to Section 3.7, if an ISP is uncertain that Algorithm A is applicable in their scenario, then they SHOULD apply Algorithm B. True, but that still doesn=E2=80=99t provide any tools for the ISP to know = either way. If there=E2=80=99s no way to know (other than trusting your neighbors= ) that the network is not in the middle of a =E2=80=9Cchallenging scenario=E2=80= =9D, then why wouldn't Algorithm B always be used? We'll be happy to reword the section more carefully if you feel that would help. You may advise us on any specific wording you would like to see added. > >Still looking at Figure 4, if the operator of ISP4 uses Algorithm A (because >he/she thinks they may not be in a "challenging scenario"), then it opens the >door to ISP2 changing its policy so that the uRPF check in ISP4 fails, as shown >in Figure 4. IOW, an attacker in ISP2 could stop advertising reachability to >some prefixes and cause ISP4 to fail the uRPF check and drop the traffic. The >victim in this case could be AS1, whose traffic (through ISP2 to ISP4) was >flowing fine and then it stopped. There are two observations that are in order here: 1. An ISP would not normally drop its own paying customer=E2=80=99s routes with malicious intent. 2. It is also hard to envision that ISP2 would attack its upstream ISP4 (in Figure 4) just to disrupt its SAV (uRPF), while that results in absolutely no gain but only causes unreachability for its (ISP2=E2=80=99s) own customer and self-inflicted loss of revenue/custom= ers. I also doubt that an operator would take actions to harm its own paying customers =E2=80=94 but the routers can be compromised anyway...or the advertisement can come from the customer itself with a NO_EXPORT community, etc.. The main case I=E2=80=99m thinking of is the compromised/rogue route= r. In any of those cases, choosing Algorithm A opens the door to vulnerabilities. Yes, they might be the same (or at least similar) as what exists with FP-uRPF =E2=80=94 but they are not mentioned. >---------------------------------------------------------------------- >COMMENT: >=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94 ... >ASes in an ISP's customer cone SHOULD be used to augment the appropriate RPF >lists." How? Note that the Introduction already sets the stage by saying that >"the routes under consideration are assumed to have been vetted based on prefix >filtering [RFC7454] and possibly (in the future) origin validation [RFC6811]." >If ROAs SHOULD be used (=C2=A73.5), why is origin validation only "possibl= y (in the >future)" considered (=C2=A71)? Maybe a better statement would be that "rou= tes >SHOULD be validated using prefix filtering, origin validation and IRR rout= e >objects". We agree with your suggested rewording in Section 1. We=E2=80=99ll use that= . What is advised in Section 3.5 regarding ROAs is as follows. In Figure 3, suppose that prefix P4 a ROA with with AS1, and AS4 (ISP4) may not have received a route for P4 (on a given customer interface). But AS4 (ISP4) has received (on that customer interface) a route for P1 wit= h the same origin AS (AS1) as in the ROA for P4. Then AS4 (ISP4) should augment its corresponding RPF list with P4 to allow the possibility that AS1 could legitimately announce a route for P4 and potentially use a SA (in a data packet) belonging in P4. We'll add this explanation in Section 3.5. Hmm=E2=80=A6 Except that the =E2=80=9Cpossibility=E2=80=9D that an announce= ment exists *and* the use as a SA, is different from AS1 really doing it. IOW, augmenting with the expectation that it may happen has its own risks=E2=80=A6 ... > >(6) [For the AD/Shepherd.] I'm assuming that the intent is for this document to >be part of BCP 84, is that correct? I'm not sure how to let the RFC Editor >know that is the intent, but it should be made clear somewhere. I am not sure that =E2=80=9Cto be part of BCP 84=E2=80=9D is the intent. The intent is that this RFC/BCP (to be published) will be a new BCP that updates BCP 84 (RFC 3704). It proposes to recommend the new EFP-uRPF which is an improvement over the FP-uRPF in RFC 3704. We=E2=80=99ll state that explicitly in the abstract as well as the introduc= tion. The draft header already states =E2=80=93 =E2=80=9CUpdates: RFC3704 (if app= roved).=E2=80=9D Updating rfc3704 and being part of the same BCP are separate considerations. To me, the fact that this document Updates rfc3704 makes it a good candidate to be part of the same BCP; a BCP can contain more than one RFC. A good example is BCP 14, which includes rfc2119 and and the more recent rfc8174. Thanks! Alvaro. --0000000000001a2a6605907ee014 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On August 18, 2019 at 5:48:04 PM, Sriram, Kotika= lapudi (Fed) (kotikalapudi.= sriram@nist.gov) wrote:

Sriram:

Hi= !

=
<= div>>-------------------------------------------------------------------= ---=C2=A0
>DISCUSS:=C2=A0
>---------------------= -------------------------------------------------=C2=A0
>=C2= =A0
>I have significant concerns about the recommendation (in = =C2=A73.7) to use Algorithm=C2=A0
>A. I think that the considerations to select an Algorithm are no= t clear and=C2=A0
>poten= tially impossible to verify. Also, the selection of Algorithm A creates a=C2=A0
>vulnerability that= could result in legitimate traffic dropped.=C2=A0
>=C2=A0
>=C2=A73.7 (Summary of Recommendations) says that "if the s= cenario does not involve=C2=A0=
>complexity...(see Section 3.3, Figure 4), then...Algorithm A...SHOU= LD be=C2=A0
>applied on = customer interfaces."=C2=A0
>=C2=A0
>From F= igure 4, how does the operator of ISP4 know that it is not in a=C2=A0
>"challenging scenario&= quot; (=C2=A73.3)? How can ISP4 tell the difference between ISP2=C2=A0
>not propagating routes vs i= t not even being connected to AS1? By definition,=C2=A0
>each autonomous system can have its own se= t of policies, which may not be known= =C2=A0
>by any of their upstreams. In short, I find the guidan= ce provided in the=C2=A0
&g= t;document to select an algorithm not clear enough to really be actionable = --=C2=A0
>specially in a= document tagged to be a BCP.=C2=A0

You are asking how does an ISP or AS operator know=C2=A0
that they have a scenario in wh= ich Algorithm A is applicable.=C2=A0<= /span>
Operators have communications at least with=C2=A0
their immediate downstream customers. So, = consider this=C2=A0
scenari= o: Operator of AS4 knows (says),=C2= =A0
=E2=80=9CI have only two direct customers AS2 (ISP2) and AS3 = (ISP3).=C2=A0
Each of them = has assured me that they have customers that=C2=A0
are all stub ASes and that these customers do not c= urrently use=C2=A0
NO_EXPOR= T on their announced routes.=C2=A0
My direct customers (ISP2 and ISP3) have mechanisms by which=C2=A0
they would notify me if thi= s ever changes.=C2=A0
They = further assure me that they would never=C2=A0
deliberately drop their customer routes.=E2=80=9D=C2=A0
This gives the operator of = AS4 the knowledge/confidence=C2=A0
that Algorithm A is applicable at their AS.=C2=A0

Precise= ly the fact that transitive assurances can=E2=80=99t be trusted about netwo= rks being well behaved is that mechanisms like ingress filtering, uRPF, RPK= I/Origin Validation, BGPSec, etc=E2=80=A6have been developed.=C2=A0 I=E2=80= =99m sorry, but it sounds=C2=A0ingenuous for the guidance to be to trust yo= ur neighbors=E2=80=A6

Quoting from rfc3704: =E2=80=9C...essentially t= rusts the downstream network to behave itself, which is not the wisest cour= se of action."

It should be emphasized that Algorithm A works=C2=A0
in scenarios like the ab= ove (customer cone depth is limited= =C2=A0
to two tiers below the ISP) provided each stub customer=C2=A0
does not attach NO_EXPO= RT on *at least* one prefix announcement=C2=A0
out of however many prefixes they announce.=C2=A0
(We=E2=80=99ll add this observa= tion in the draft.)=C2=A0
<= br>There can be many realistic scenarios like the above that exist=C2=A0
at the edges of the Internet.= But just one is enough to=C2=A0
justify the inclusion of Algorithm A in the recommendations (Sec. 3.7= ).=C2=A0
(Note: uRPF is exp= ected to work best at the edges of the Internet.)=C2=A0


<= /div>
Further, the feasible path uRPF (FP-uRPF) is already a BCP (part of BCP 8= 4).=C2=A0
If an operator de= ems their scenario fit for use of FP-uRPF,=C2=A0
then the EFP-uRPF with Algorithm A is also applicable= in that scenario and=C2=A0performs equally or better (i.e., lower false positive rate for SA invalid= ) than FP-uRPF.=C2=A0
Of co= urse, the EFP-uRPF works better under less restrictive=C2=A0
conditions than required for FP-uRPF as e= xplained in the draft.=C2=A0=C2=A0

I couldn=E2=80=99t find much in terms of guidance in rfc3704= about when using FP-uRPF is recommended, except for this: "Feasible P= ath RPF=E2=80=A6is suitable in all the scenarios where Strict RPF is, but m= ultihomed or asymmetric scenarios in particular.=C2=A0 However, one must re= member that Feasible RPF assumes the consistent origination and propagation= of routing information to work; the implications of this must be understoo= d especially if a prefix advertisement passes through third parties.=E2=80= =9D =C2=A0

I think that the guidance in rfc3704 is about the same as = the guidance in this document, plus the fact that some of the potential iss= ues with trusting other networks are at least mentioned there.=C2=A0 Howeve= r, I don=E2=80=99t think that there=E2=80=99s enough guidance in rfc3704 fo= r this document to simply point at it =E2=80=94 the same questions would ap= ply: how would an operator know that "consistent origination and propa= gation of routing information=E2=80=9D is present?


=
Of course, ac= cording to Section 3.7, if an ISP is uncertain that=C2=A0
Algorithm A is applicable in their scenario,= then they SHOULD apply Algorithm B.= =C2=A0

True, but that still = doesn=E2=80=99t provide any tools for the ISP to know either way.=C2=A0 If = there=E2=80=99s no way to know (other than trusting your neighbors) that th= e network is not in the middle of a =E2=80=9Cchallenging scenario=E2=80=9D,= then why wouldn't Algorithm B always be used?


=
We'll be = happy to reword the section more carefully if you feel=C2=A0
that would help. You may advise us on any= specific wording=C2=A0
you= would like to see added.=C2=A0

>=C2=A0
>Sti= ll looking at Figure 4, if the operator of ISP4 uses Algorithm A (because=C2=A0
>he/she thinks they= may not be in a "challenging scenario"), then it opens the=C2=A0
>door to ISP2 changing = its policy so that the uRPF check in ISP4 fails, as shown=C2=A0
>in Figure 4. IOW, an attacker in I= SP2 could stop advertising reachability to=C2=A0
>some prefixes and cause ISP4 to fail the uRPF che= ck and drop the traffic. The=C2=A0
>victim in this case could be AS1, whose traffic (through ISP2 t= o ISP4) was=C2=A0
>flowi= ng fine and then it stopped.=C2=A0

There are two observations that are in order here:=C2=A0
1. An ISP would not normally dr= op its own paying customer=E2=80=99s= =C2=A0
routes with malicious intent.=C2=A0
2. It is also hard to envision that ISP2 would at= tack its upstream ISP4=C2=A0(in Figure 4) just to disrupt its SAV (uRPF), while that results in=C2=A0
absolutely no gain but onl= y causes unreachability for=C2=A0
its (ISP2=E2=80=99s) own customer and self-inflicted loss of revenue= /customers.=C2=A0=C2=A0

I also doubt that an operator would take actions to harm its own payi= ng customers =E2=80=94 but the routers can be compromised anyway...or the a= dvertisement can come from the customer itself with a NO_EXPORT community, = etc..=C2=A0 The main case I=E2=80=99m thinking of is the compromised/rogue = router. =C2=A0 =C2=A0In any of those cases, choosing Algorithm A opens the = door to vulnerabilities.=C2=A0 Yes, they might be the same (or at least sim= ilar) as what exists with FP-uRPF =E2=80=94 but they are not mentioned.

=



>-----------------------------------------------= -----------------------=C2=A0<= br>>COMMENT:=C2=A0
>= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=C2=A0=C2=A0

...


>ASes in an ISP's customer cone SHOULD be used to augment th= e appropriate RPF=C2=A0
>= ;lists." How? Note that the Introduction already sets the stage by say= ing that=C2=A0
>"th= e routes under consideration are assumed to have been vetted based on prefi= x=C2=A0
>filtering [RFC7= 454] and possibly (in the future) origin validation [RFC6811]."=C2=A0
>If ROAs SHOULD be used = (=C2=A73.5), why is origin validation only "possibly (in the=C2=A0
>future)" considered (= =C2=A71)? Maybe a better statement would be that "routes=C2=A0
>SHOULD be validated using pref= ix filtering, origin validation and IRR route=C2=A0
>objects".=C2=A0

We agree with your suggested rewording in Sectio= n 1. We=E2=80=99ll use that.=C2=A0
What is advised in Section 3.5 regarding ROAs is as follows.=C2=A0
In Figure 3, suppose that p= refix P4 a ROA with with AS1,=C2=A0
and AS4 (ISP4) may not have received a route for P4 (on a given cu= stomer interface).=C2=A0
Bu= t AS4 (ISP4) has received (on that customer interface) a route for P1 with<= span class=3D"Apple-converted-space">=C2=A0
the same origin AS (A= S1) as in the ROA for P4.=C2=A0
Then AS4 (ISP4) should augment its corresponding RPF list with P4=C2=A0
to allow the possibility = that AS1 could legitimately announce= =C2=A0
a route for P4 and potentially use a SA (in a data packet)= belonging in P4.=C2=A0=C2=A0
We'll add this explanat= ion in Section 3.5.=C2=A0

Hmm=E2=80=A6 Except that the =E2=80=9Cp= ossibility=E2=80=9D that an announcement exists *and* the use as a SA, is d= ifferent from AS1 really doing it.=C2=A0 IOW, augmenting with the expectati= on that it may happen has its own risks=E2=80=A6


...

><= span class=3D"Apple-converted-space">=C2=A0
>(6) [For the AD/S= hepherd.] I'm assuming that the intent is for this document to=C2=A0
>be part of BCP 84, is tha= t correct? I'm not sure how to let the RFC Editor=C2=A0
>know that is the intent, but it should= be made clear somewhere.=C2=A0

I am not sure that =E2=80=9Cto be part of BCP 84=E2=80=9D is the i= ntent.=C2=A0
The intent is = that this RFC/BCP (to be published) will be=C2=A0
a new BCP that updates BCP 84 (RFC 3704).=C2=A0
It proposes to recommend the ne= w EFP-uRPF which is=C2=A0
a= n improvement over the FP-uRPF in RFC 3704.=C2=A0
We=E2=80=99ll state that explicitly in the abstract = as well as the introduction.=C2=A0
The draft header already states =E2=80=93 =E2=80=9CUpdates: RFC3704= (if approved).=E2=80=9D=C2=A0=

Updating rfc3704 and being part of= the same BCP are separate considerations.=C2=A0 To me, the fact that this = document Updates rfc3704 makes it a good candidate to be part of the same B= CP; a BCP can contain more than one RFC.

A good example is BCP 14, wh= ich includes rfc2119 and and the more recent rfc8174.


Than= ks!

Alvaro.

--0000000000001a2a6605907ee014-- From nobody Tue Aug 20 07:29:27 2019 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF4012009E; Tue, 20 Aug 2019 07:29:26 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 UjldxbOAB4rT; Tue, 20 Aug 2019 07:29:23 -0700 (PDT) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2121.outbound.protection.outlook.com [40.107.91.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20208120094; Tue, 20 Aug 2019 07:29:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=khfdzUDn5UFCrYXL08cMH7RAo9zBxajafhiX1ZAecIqHRgHfHg6SmqAvQr+lEeC6iE0/b71YU+rwr7kUTJ0zkh1goYzFMKzN0oBtdEAsD/CSdwnsPEwFszZjtEUEH6ZB+dx6tjDiwwFjfj9an58Gs7+sBskVrF5Q6k+UCn0oGiI0EetzQ7H4DkJIzI+tGdh90rdf5Ay8cRhIN2Txk+DBBaHe6KH9s+s8Kvgi2T0Pe1DIdMo6ZWvqSe+oJDge0yQzaWaoIJ2jugODZWqZQ3l12DKqRI8C1iglwfxc8dseQoFjrDkQh5SsDRqpo9TttjM+zrOIyfMugr2RGJRxiSmJYg== 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=7yV19tUeoyCSLV/2Xy/MhZ392rFOShEGatEh1SBrgEI=; b=U6Vewy19FRqzDNNJcDDI9NIx7HlFqWYvhA75eacA6R5fQ5a/O1dLsP4vRxU79jszlwIZFWJcUBbhu1DpboKgGI8cd8qssE+K9mvTHc/epum4K5lNnvHQgRxaz2AIgv3Kvfcx5V8MVofF6wDQyQ1WwfX1P/g6tleIbYTJjurNe4aPNwUpnZR1yzQm/3A8PEQePodTkZjM4TALl/szBIfytcxgxNPYf6DA9KGxbUibU7f9Bi2Z/BE3NnWOTZrHNTNn6S9aWG7mzGjDEn97Cf88Mf25WnF3CSYGYzhZ1hW6Dlpxjaxy1r6GPGJg/TH3vrm/y9jMVikZS4uLjbZFB24Vmg== 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=7yV19tUeoyCSLV/2Xy/MhZ392rFOShEGatEh1SBrgEI=; b=ymcjEockqhuyo73xJ4Co3uOhM7I0mSTs96bXtCBtAtnYRFBgUmQZ9Q3uoXOHLR79TOg1g1Mh/86Bu9MTckwWYubt1nMGkIUSlsL6ASArDMRUlHIUUoCG06wByqxbdxDCxQ4QjXc67Bhrj2hfTgrGDs3NvQ3m0042sQBDX7ziOI0= Received: from DM6PR09MB3019.namprd09.prod.outlook.com (20.178.2.203) by DM6PR09MB3081.namprd09.prod.outlook.com (20.178.3.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.18; Tue, 20 Aug 2019 14:29:21 +0000 Received: from DM6PR09MB3019.namprd09.prod.outlook.com ([fe80::fc5a:9648:8e8f:7968]) by DM6PR09MB3019.namprd09.prod.outlook.com ([fe80::fc5a:9648:8e8f:7968%6]) with mapi id 15.20.2178.018; Tue, 20 Aug 2019 14:29:21 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Alvaro Retana , The IESG CC: "opsec-chairs@ietf.org" , Sandra Murphy , "Murphy, Sandra" , "opsec@ietf.org" , "draft-ietf-opsec-urpf-improvements@ietf.org" , Jen Linkova Thread-Topic: Alvaro Retana's Discuss on draft-ietf-opsec-urpf-improvements-03: (with DISCUSS and COMMENT) Thread-Index: AQHVVH41+WK2q56zSkaIVPY4TX30Q6cBbRMZgAGRGwCAARoHbw== Date: Tue, 20 Aug 2019 14:29:21 +0000 Message-ID: References: <156599290421.23877.9763694862590191063.idtracker@ietfa.amsl.com> , In-Reply-To: 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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.223.129] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 29275abf-1b1e-4e7b-06b0-08d7257acaa1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DM6PR09MB3081; x-ms-traffictypediagnostic: DM6PR09MB3081: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 013568035E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(136003)(346002)(366004)(39860400002)(199004)(189003)(51444003)(30864003)(76116006)(91956017)(256004)(14444005)(316002)(229853002)(6246003)(7736002)(6506007)(305945005)(74316002)(478600001)(8936002)(54906003)(25786009)(53936002)(33656002)(4326008)(76176011)(81166006)(81156014)(7696005)(99286004)(14454004)(110136005)(8676002)(6116002)(186003)(52536014)(3846002)(55016002)(66574012)(486006)(476003)(446003)(11346002)(5660300002)(9686003)(102836004)(71200400001)(71190400001)(66066001)(2906002)(6436002)(66946007)(66476007)(5024004)(66556008)(64756008)(66446008)(26005)(86362001)(87944003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR09MB3081; H:DM6PR09MB3019.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: L49M660EpZ1tAkOOXqiZpHOVu8KK9I7Qz93MjChzbC0peSZU0+7SlvSGZ7jO2hARi3CtKYHaYF4C2JB+cmsU4lXiab6qM/vi6Q4JapSeGF8SIlNo+m0a14c12DDWviVRWV+YSmejc+Khndrrxh3mf5E2xA9lUB0JRtk1irp35CADa1ZE/aDR3cqS2Ofxt8/+rKH59g5PV8GfbwxJqVSe1NDl7DtzzR4z+mhJgEDIe/DDybV6FyrXRXpXjSRFNZroxUkuwVWzOLpSpvb4/w5jUYcS0/0YGef+2TYoaSkTiVZmaj1LHn9dyP7Hy3m4If8mNos3zTNbo+OKzLTHTcLlXtOcHUAr7MurDc35PxcOF/lmRJuL10dlJmMXT90JDc1tB/ZweQxG2KmneE8adhJ9wFO4wofieqjypf11XOniVmU= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 29275abf-1b1e-4e7b-06b0-08d7257acaa1 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2019 14:29:21.0533 (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: qM/2z+DTxXIo4XSCqsd7CNIpXiTVCVuzwROelSB4I8LCsvTRgunyiF6F1X6WvEbDuZTKZ+AKYIWVdbVqX5w6Tw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR09MB3081 Archived-At: Subject: Re: [OPSEC] Alvaro Retana's Discuss on draft-ietf-opsec-urpf-improvements-03: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 14:29:26 -0000 Alvaro, Responses below inline. >>>----------------------------------------------------------------------=20 >>>DISCUSS:=20 >>>----------------------------------------------------------------------=20 >>>=20 >>>I have significant concerns about the recommendation (in =A73.7) to use = Algorithm=20 >>>A. I think that the considerations to select an Algorithm are not clear = and=20 >>>potentially impossible to verify. Also, the selection of Algorithm A cre= ates a=20 >>>vulnerability that could result in legitimate traffic dropped.=20 >>>=20 >>>=A73.7 (Summary of Recommendations) says that "if the scenario does not = involve=20 >>>complexity...(see Section 3.3, Figure 4), then...Algorithm A...SHOULD be= =20 >>>applied on customer interfaces."=20 >>>=20 >>>From Figure 4, how does the operator of ISP4 know that it is not in a=20 >>>"challenging scenario" (=A73.3)? How can ISP4 tell the difference betwee= n ISP2=20 >>>not propagating routes vs it not even being connected to AS1? By definit= ion,=20 >>>each autonomous system can have its own set of policies, which may not b= e known=20 >>>by any of their upstreams. In short, I find the guidance provided in the= =20 >>>document to select an algorithm not clear enough to really be actionable= --=20 >>>specially in a document tagged to be a BCP.=20 >> >>You are asking how does an ISP or AS operator know=20 >>that they have a scenario in which Algorithm A is applicable.=20 >>Operators have communications at least with=20 >>their immediate downstream customers. So, consider this=20 >>scenario: Operator of AS4 knows (says),=20 >>=93I have only two direct customers AS2 (ISP2) and AS3 (ISP3).=20 >>Each of them has assured me that they have customers that=20 >>are all stub ASes and that these customers do not currently use=20 >>NO_EXPORT on their announced routes.=20 >>My direct customers (ISP2 and ISP3) have mechanisms by which=20 >>they would notify me if this ever changes.=20 >>They further assure me that they would never=20 >>deliberately drop their customer routes.=94=20 >>This gives the operator of AS4 the knowledge/confidence=20 >>that Algorithm A is applicable at their AS.=20 >Precisely the fact that transitive assurances can=92t be trusted about net= works being well behaved is that mechanisms like ingress filtering, uRPF, R= PKI/Origin Validation, BGPSec, etc=85have been developed. I=92m sorry, but= it sounds ingenuous for the guidance to be to trust your neighbors=85 First, I notice that BCP 84 does not use RFC2119/RFC 8174 language.=20 So, I think this document can also avoid using upper case SHOULD etc. Having noted that, I feel there is a difference between saying,=20 =93ISP should trust their neighbor and should use Algorithm A=94=20 versus saying, =93if an ISP has knowledge (by whatever mechanism they choos= e)=20 that the scenario they are in is amenable to Algorithm A,=20 then they may consider using it in their AS.=94 The draft clearly intends t= he latter. I think we shouldn=92t dismiss the possibility some ISPs may have the means to rule out the NO_EXPORT complexity.=20 The document would not specify how the determination is made;=20 would not even say that it is required. However, if an ISP finds that they have rapport with their direct customers or that they have access to their RIB-in feeds or whatever, and thereby able to determine that Algorithm A can be used, that is their d= ecision. (I am not saying that the immediate above sentence needs to be stated in th= e draft.) In most cases, an ISP will likely find itself using Algorithm B. How about the following change in the draft in Section 3.7? OLD text: 3. For all other scenarios: * If the scenario does not involve complexity such as NO_EXPORT of routes (see Section 3.3, Figure 4), then the enhanced feasible-path uRPF method in Algorithm A (see Section 3.1.1) SHOULD be applied on customer interfaces. * Else, if the scenario involves the complexity then the enhanced feasible-path uRPF method in Algorithm B (see Section 3.4) SHOULD be applied on customer interfaces. NEW text: 3. For all other scenarios: * If the ISP has some means to ascertain that the scenario does=20 not involve complexity such as NO_EXPORT of routes (see Section 3.3, Figure 4), then the enhanced feasible-path uRPF method in Algorithm A (see Section 3.1.1) may be applied on customer interfaces. * If there is a possibility that the scenario may involve the compl= exity, or if the ISP simply wishes to avoid any risk associated with Alg= orithm A (see Section 3.3), then the enhanced feasible-path uRPF method=20 in Algorithm B (see Section 3.4) should be applied on customer in= terfaces. =85. >>It should be emphasized that Algorithm A works=20 >>in scenarios like the above (customer cone depth is limited=20 >>to two tiers below the ISP) provided each stub customer=20 >>does not attach NO_EXPORT on *at least* one prefix announcement=20 >>out of however many prefixes they announce.=20 >>(We=92ll add this observation in the draft.)=20 >> >>There can be many realistic scenarios like the above that exist=20 >>at the edges of the Internet. But just one is enough to=20 >>justify the inclusion of Algorithm A in the recommendations (Sec. 3.7).=20 >>(Note: uRPF is expected to work best at the edges of the Internet.)=20 >> >>Further, the feasible path uRPF (FP-uRPF) is already a BCP (part of BCP 8= 4).=20 >>If an operator deems their scenario fit for use of FP-uRPF,=20 >>then the EFP-uRPF with Algorithm A is also applicable in that scenario an= d=20 >>performs equally or better (i.e., lower false positive rate for SA invali= d) than FP-uRPF.=20 >>Of course, the EFP-uRPF works better under less restrictive=20 >>conditions than required for FP-uRPF as explained in the draft.=20 =20 >I couldn=92t find much in terms of guidance in rfc3704 about when using FP= -uRPF is recommended, except for this: "Feasible Path RPF=85is suitable in = all the scenarios where Strict RPF is, but multihomed or asymmetric scenari= os in particular. However, one must remember that Feasible RPF assumes the= consistent origination and propagation of routing information to work; the= implications of this must be understood especially if a prefix advertiseme= nt passes through third parties.=94 =20 >I think that the guidance in rfc3704 is about the same as the guidance in = this document, plus the fact that some of the potential issues with trustin= g other networks are at least mentioned there. However, I don=92t think th= at there=92s enough guidance in rfc3704 for this document to simply point a= t it =97 the same questions would apply: how would an operator know that "c= onsistent origination and propagation of routing information=94 is present? As the draft notes, EFP-uRPF (Algorithm A) is more tolerant than FP-uRPF=20 regarding "consistent origination and propagation of routing information=94= .=20 In fact, ASes not using NO_EXPORT on *all* originated prefixes=20 paves the way for use of Algorithm A.=20 Of course, Algorithm B is highly flexible/accommodative. =20 > >>Of course, according to Section 3.7, if an ISP is uncertain that=20 >>Algorithm A is applicable in their scenario, then they SHOULD apply Algor= ithm B.=20 >True, but that still doesn=92t provide any tools for the ISP to know eithe= r way. If there=92s no way to know (other than trusting your neighbors) th= at the network is not in the middle of a =93challenging scenario=94, then w= hy wouldn't Algorithm B always be used? Yes, it may end up being true that Algorithm B is always used.=20 We also want to let ISPs make their own decision about=20 applicability of Algorithm A. I am hoping for agreement on the proposed=20 wording change in Section 3.7 (with modifications you may suggest). >>>=20 >>>Still looking at Figure 4, if the operator of ISP4 uses Algorithm A (bec= ause=20 >>>he/she thinks they may not be in a "challenging scenario"), then it open= s the=20 >>>door to ISP2 changing its policy so that the uRPF check in ISP4 fails, a= s shown=20 >>>in Figure 4. IOW, an attacker in ISP2 could stop advertising reachabilit= y to=20 >>>some prefixes and cause ISP4 to fail the uRPF check and drop the traffic= . The=20 >>>victim in this case could be AS1, whose traffic (through ISP2 to ISP4) w= as=20 >>>flowing fine and then it stopped.=20 >> >>There are two observations that are in order here:=20 >>1. An ISP would not normally drop its own paying customer=92s=20 >>routes with malicious intent.=20 >>2. It is also hard to envision that ISP2 would attack its upstream ISP4=20 >>(in Figure 4) just to disrupt its SAV (uRPF), while that results in=20 >>absolutely no gain but only causes unreachability for=20 >>its (ISP2=92s) own customer and self-inflicted loss of revenue/customers.= =20 >I also doubt that an operator would take actions to harm its own paying cu= stomers =97 but the routers can be compromised anyway...or the advertisemen= t can come from the customer itself with a NO_EXPORT community, etc.. The = main case I=92m thinking of is the compromised/rogue router. In any of t= hose cases, choosing Algorithm A opens the door to vulnerabilities. Yes, t= hey might be the same (or at least similar) as what exists with FP-uRPF =97= but they are not mentioned. Even for other BGP security mechanisms, the issue of compromise=20 of a router or RPKI/ROA management system exists. Due to such compromises, malicious ROAs may get created, AS prepend count in BGPsec may be changed maliciously, or the route leak=20 protection (RLP) attribute in the route leak solution may be maliciously al= tered. We hope that such malicious activity is 1% or less of the attacks, and that we are successfully addressing the other 99% in our solution metho= ds. I=92ll add text accordingly for EPF-uRPF/Algorithm A in the Security Consid= erations section. =20 >>>----------------------------------------------------------------------=20 >>>COMMENT:=20 >>>=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97= =97=97=97=97=97=97=97=97=97=97=97 =20 >... >>>ASes in an ISP's customer cone SHOULD be used to augment the appropriate= RPF=20 >>>lists." How? Note that the Introduction already sets the stage by saying= that=20 >>>"the routes under consideration are assumed to have been vetted based on= prefix=20 >>>filtering [RFC7454] and possibly (in the future) origin validation [RFC6= 811]."=20 >>>If ROAs SHOULD be used (=A73.5), why is origin validation only "possibly= (in the=20 >>>future)" considered (=A71)? Maybe a better statement would be that "rout= es=20 >>>SHOULD be validated using prefix filtering, origin validation and IRR ro= ute=20 >>>objects".=20 >> >>We agree with your suggested rewording in Section 1. We=92ll use that.=20 >>What is advised in Section 3.5 regarding ROAs is as follows.=20 >>In Figure 3, suppose that prefix P4 a ROA with AS1,=20 >>and AS4 (ISP4) may not have received a route for P4 (on a given customer = interface).=20 >>But AS4 (ISP4) has received (on that customer interface) a route for P1 w= ith=20 >>the same origin AS (AS1) as in the ROA for P4.=20 >>Then AS4 (ISP4) should augment its corresponding RPF list with P4=20 >>to allow the possibility that AS1 could legitimately announce=20 >>a route for P4 and potentially use a SA (in a data packet) belonging in P= 4. =20 >>We'll add this explanation in Section 3.5.=20 >Hmm=85 Except that the =93possibility=94 that an announcement exists *and*= the use as a SA, is different from AS1 really doing it. IOW, augmenting w= ith the expectation that it may happen has its own risks=85 > Yep, there is that trade-off. Here we choose to further reduce the possibil= ity=20 of false positive (for SA invalid) at the expense of some other risk. Yes, a malicious actor at another AS in the neighborhood=20 within the customer cone might take advantage to some extent.=20 But the same vulnerability exists even if the update were announced. =20 >... >>>=20 >>>(6) [For the AD/Shepherd.] I'm assuming that the intent is for this docu= ment to=20 >>>be part of BCP 84, is that correct? I'm not sure how to let the RFC Edit= or=20 >>>know that is the intent, but it should be made clear somewhere.=20 >> >>I am not sure that =93to be part of BCP 84=94 is the intent.=20 >>The intent is that this RFC/BCP (to be published) will be=20 >>a new BCP that updates BCP 84 (RFC 3704).=20 >>It proposes to recommend the new EFP-uRPF which is=20 >>an improvement over the FP-uRPF in RFC 3704.=20 >>We=92ll state that explicitly in the abstract as well as the introduction= .=20 >>The draft header already states =96 =93Updates: RFC3704 (if approved).=94= =20 >Updating rfc3704 and being part of the same BCP are separate consideration= s. To me, the fact that this document Updates rfc3704 makes it a good cand= idate to be part of the same BCP; a BCP can contain more than one RFC. > >A good example is BCP 14, which includes rfc2119 and the more recent rfc81= 74. Oh, that is good to know. Thanks for clarifying. I am fine with your sugges= tion. Will double check with co-authors and Sandy. Thank you. Sriram From nobody Tue Aug 20 08:35:09 2019 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D920E12095B; Tue, 20 Aug 2019 08:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 GVm3fnIJTUJb; Tue, 20 Aug 2019 08:35:05 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C46551200EB; Tue, 20 Aug 2019 08:35:04 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id t50so3838010edd.2; Tue, 20 Aug 2019 08:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=xf5edEsH0YdiJfgjhf/IsXNHBqHwI5KgKPs+9qwzeh0=; b=hH3oamedFM3zxRBlNoUqpVbdjA6HyMvUVvX+uBrhPI0bTF8WjiC8iZsCT6YjxzBcRm hvyHLw2YpVlgU/cq+ifj2WyD6/QYTOSNG4GyDXOlm46Xb36qPuNN64IO9hibHxI6h3Pw zsHXxebpTWJq17POyVAfdI8X5Mex/ArQb+nvmNswWvUl0dV34F4qT7UBK6j6+N3tCx3T lnd8tavZiy3ODDo8UmPC/dOsOppSoJfz9DBnwHThvAFIA9zojQDAmKWVUNhEf1MzFCUk OxXkzwdf91IJpGFZ6xTHrzTrTZQEtuPvr4bhcwlQcfFWrIwNPRhD4MsSOqbMz07XtRvP DWfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=xf5edEsH0YdiJfgjhf/IsXNHBqHwI5KgKPs+9qwzeh0=; b=L4sckA6gvZyHX1YY7lW7LDOTm2g/uWcZ+MRdlZYGzNjlXkCfj26JpU+WwH0t25lilw 6jLqKPvy8lki9hSdmJfM6lBcVsjEGLG8YlqqKkWuAEzr37IHErlrYMM+7QqkW6g3yARr 5t11SDExqeq8XAtjdIXuMAGjgSfGD/9lfOHopvFgAwJZy6Q492eLHgD51+L0pOScRUXO x8X6rewV+fFoJNDL5hk6b9/na790QRdZdVQ2anVtTJ1wQIF9AhSm+4q8z3eiSkVWfxz1 T2VYVAjTKNzZcP53NT0I0d5umLmEUxhEahlAdNAo3yVhC0VCNEM3vQKj4PttOKKTqBC2 poXg== X-Gm-Message-State: APjAAAVFXBbur9iee9UI+2XXkRPkxF2bDs2nFJF1Rw//ALDj67EVMyGy tRk1LIRB5hKY+WV6rkD5rL5G7NFO44DThGgccPM= X-Google-Smtp-Source: APXvYqx/x3vAtbKjR+bolNm9yPIrkn2JHExMMZXCW2/Tw8f41U8dDC8VDgG0A9MqUhrcabsrJwDMWTLldSLh35N7ZFo= X-Received: by 2002:a17:906:e241:: with SMTP id gq1mr26328531ejb.265.1566315303251; Tue, 20 Aug 2019 08:35:03 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 20 Aug 2019 11:35:02 -0400 From: Alvaro Retana In-Reply-To: References: <156599290421.23877.9763694862590191063.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Date: Tue, 20 Aug 2019 11:35:02 -0400 Message-ID: To: "Sriram, Kotikalapudi (Fed)" , The IESG Cc: "Murphy, Sandra" , Sandra Murphy , "draft-ietf-opsec-urpf-improvements@ietf.org" , Jen Linkova , "opsec@ietf.org" , "opsec-chairs@ietf.org" Content-Type: multipart/alternative; boundary="00000000000041b1af05908e3339" Archived-At: Subject: Re: [OPSEC] Alvaro Retana's Discuss on draft-ietf-opsec-urpf-improvements-03: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 15:35:08 -0000 --00000000000041b1af05908e3339 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On August 20, 2019 at 10:29:22 AM, Sriram, Kotikalapudi (Fed) ( kotikalapudi.sriram@nist.gov) wrote: Sriram: Hi! Let=E2=80=99s cut to the chase=E2=80=A6 >>Of course, according to Section 3.7, if an ISP is uncertain that >>Algorithm A is applicable in their scenario, then they SHOULD apply Algorithm B. >True, but that still doesn=E2=80=99t provide any tools for the ISP to know= either way. If there=E2=80=99s no way to know (other than trusting your neighbors)= that the network is not in the middle of a =E2=80=9Cchallenging scenario=E2=80= =9D, then why wouldn't Algorithm B always be used? Yes, it may end up being true that Algorithm B is always used. We also want to let ISPs make their own decision about applicability of Algorithm A. I am hoping for agreement on the proposed wording change in Section 3.7 (with modifications you may suggest). It may be just me=E2=80=A6in fact, I didn=E2=80=99t find significant discus= sion about the applicability of the algorithms on the list, beyond the initial discussion of draft-sriram-opsec-urpf-improvements-00, where the =E2=80=9Cchallenging scenario=E2=80=9D was introduced because (in my interpretation) the origina= l proposal didn=E2=80=99t address real deployments. Given that Algorithm B is more flexible, and that the limitations from Algorithm A are overcome (=C2=A73.4), I would like to see B be the recommendation. I am ok if Algorithm A is mentioned as an alternative (not a recommendation); one that is less flexible and has specific limitations =E2= =80=94 even if those limitations are not expected/assumed, the vulnerability to a change in conditions should be clearly spelled out. >>>Still looking at Figure 4, if the operator of ISP4 uses Algorithm A (because >>>he/she thinks they may not be in a "challenging scenario"), then it opens the >>>door to ISP2 changing its policy so that the uRPF check in ISP4 fails, as shown >>>in Figure 4. IOW, an attacker in ISP2 could stop advertising reachability to >>>some prefixes and cause ISP4 to fail the uRPF check and drop the traffic. The >>>victim in this case could be AS1, whose traffic (through ISP2 to ISP4) was >>>flowing fine and then it stopped. >> >>There are two observations that are in order here: >>1. An ISP would not normally drop its own paying customer=E2=80=99s >>routes with malicious intent. >>2. It is also hard to envision that ISP2 would attack its upstream ISP4 >>(in Figure 4) just to disrupt its SAV (uRPF), while that results in >>absolutely no gain but only causes unreachability for >>its (ISP2=E2=80=99s) own customer and self-inflicted loss of revenue/cust= omers. >I also doubt that an operator would take actions to harm its own paying customers =E2=80=94 but the routers can be compromised anyway...or the advertisement can come from the customer itself with a NO_EXPORT community, etc.. The main case I=E2=80=99m thinking of is the compromised/rogue router= . In any of those cases, choosing Algorithm A opens the door to vulnerabilities. Yes, they might be the same (or at least similar) as what exists with FP-uRPF =E2=80=94 but they are not mentioned. Even for other BGP security mechanisms, the issue of compromise of a router or RPKI/ROA management system exists. Due to such compromises, malicious ROAs may get created, AS prepend count in BGPsec may be changed maliciously, or the route leak protection (RLP) attribute in the route leak solution may be maliciously altered. We hope that such malicious activity is 1% or less of the attacks, and that we are successfully addressing the other 99% in our solution methods. I=E2=80=99ll add text accordingly for EPF-uRPF/Algorithm A in the Security Considerations section. We all hope that malicious activity on the Internet is kept to a minimum=E2=80=A6but that doesn=E2=80=99t mean that the risk doesn=E2=80=99t= exist, or that the effect of minimal activity will also be minimal. Not all prefixes are made the same: affecting just one could have significant consequences. >>>---------------------------------------------------------------------- >>>COMMENT: >>>=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94 >... >>>ASes in an ISP's customer cone SHOULD be used to augment the appropriate RPF >>>lists." How? Note that the Introduction already sets the stage by saying that >>>"the routes under consideration are assumed to have been vetted based on prefix >>>filtering [RFC7454] and possibly (in the future) origin validation [RFC6811]." >>>If ROAs SHOULD be used (=C2=A73.5), why is origin validation only "possi= bly (in the >>>future)" considered (=C2=A71)? Maybe a better statement would be that "r= outes >>>SHOULD be validated using prefix filtering, origin validation and IRR route >>>objects". >> >>We agree with your suggested rewording in Section 1. We=E2=80=99ll use th= at. >>What is advised in Section 3.5 regarding ROAs is as follows. >>In Figure 3, suppose that prefix P4 a ROA with AS1, >>and AS4 (ISP4) may not have received a route for P4 (on a given customer interface). >>But AS4 (ISP4) has received (on that customer interface) a route for P1 with >>the same origin AS (AS1) as in the ROA for P4. >>Then AS4 (ISP4) should augment its corresponding RPF list with P4 >>to allow the possibility that AS1 could legitimately announce >>a route for P4 and potentially use a SA (in a data packet) belonging in P4. >>We'll add this explanation in Section 3.5. >Hmm=E2=80=A6 Except that the =E2=80=9Cpossibility=E2=80=9D that an announc= ement exists *and* the use as a SA, is different from AS1 really doing it. IOW, augmenting with the expectation that it may happen has its own risks=E2=80=A6 > Yep, there is that trade-off. Here we choose to further reduce the possibility of false positive (for SA invalid) at the expense of some other risk. Yes, a malicious actor at another AS in the neighborhood within the customer cone might take advantage to some extent. But the same vulnerability exists even if the update were announced. Yes=E2=80=A6but it is important to clearly mention the known vulnerabilitie= s of the solutions being proposed. Thanks! Alvaro. --00000000000041b1af05908e3339 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On August 20, 2019 at 10:29:22 AM, Sriram, Kotik= alapudi (Fed) (kotikalapudi= .sriram@nist.gov) wrote:

Sriram:

H= i!

Let=E2=80=99s cu= t to the chase=E2=80=A6

>>Of course, according to Section 3.7, if an ISP i= s uncertain that=C2=A0
>= >Algorithm A is applicable in their scenario, then they SHOULD apply Alg= orithm B.=C2=A0
>True, b= ut that still doesn=E2=80=99t provide any tools for the ISP to know either = way. If there=E2=80=99s no way to know (other than trusting your neighbors)= that the network is not in the middle of a =E2=80=9Cchallenging scenario= =E2=80=9D, then why wouldn't Algorithm B always be used?=C2=A0

Yes, it may end up being true t= hat Algorithm B is always used.=C2=A0=
We also want to let ISPs make their own decision about=C2=A0
applicability of Algorithm A. = I am hoping for agreement on the proposed=C2=A0
wording change in Section 3.7 (with modifications you = may suggest).=C2=A0

It may be just me=E2=80=A6in fact, I di= dn=E2=80=99t find significant discussion about the applicability of the alg= orithms on the list, beyond the initial discussion of=C2=A0draft-sriram-ops= ec-urpf-improvements-00, where the =E2=80=9Cchallenging scenario=E2=80=9D w= as introduced because (in my interpretation) the original proposal didn=E2= =80=99t address real deployments.

Given that Algorithm B is more flex= ible, and that the limitations from Algorithm A are overcome (=C2=A73.4), I= would like to see B be the recommendation.

I am ok if Algorithm A is= mentioned as an alternative (not a recommendation); one that is less flexi= ble and has specific limitations =E2=80=94 even if those limitations are no= t expected/assumed, the vulnerability to a change in conditions should be c= learly spelled out.



>>>Still looking at Figu= re 4, if the operator of ISP4 uses Algorithm A (because=C2=A0
>>&g= t;he/she thinks they may not be in a "challenging scenario"), the= n it opens the=C2=A0
>&g= t;>door to ISP2 changing its policy so that the uRPF check in ISP4 fails= , as shown=C2=A0
>>&g= t;in Figure 4. IOW, an attacker in ISP2 could stop advertising reachability= to=C2=A0
>>>some = prefixes and cause ISP4 to fail the uRPF check and drop the traffic. The=C2=A0
>>>victim in t= his case could be AS1, whose traffic (through ISP2 to ISP4) was=C2=A0
>>>flowing fine and th= en it stopped.=C2=A0

&g= t;>=C2=A0
>>There = are two observations that are in order here:=C2=A0
>>1. An ISP would not normally drop its own p= aying customer=E2=80=99s=C2=A0=
>>routes with malicious intent.=C2=A0
>>2. It is also hard to envision that ISP2 would= attack its upstream ISP4=C2=A0
>>(in Figure 4) just to disrupt its SAV (uRPF), while that resul= ts in=C2=A0
>>absolut= ely no gain but only causes unreachability for=C2=A0
>>its (ISP2=E2=80=99s) own customer and sel= f-inflicted loss of revenue/customers.=C2=A0=C2=A0

&g= t;I also doubt that an operator would take actions to harm its own paying c= ustomers =E2=80=94 but the routers can be compromised anyway...or the adver= tisement can come from the customer itself with a NO_EXPORT community, etc.= . The main case I=E2=80=99m thinking of is the compromised/rogue router. In= any of those cases, choosing Algorithm A opens the door to vulnerabilities= . Yes, they might be the same (or at least similar) as what exists with FP-= uRPF =E2=80=94 but they are not mentioned.=C2=A0


Even for other BGP security mechanisms, the i= ssue of compromise=C2=A0
of= a router or RPKI/ROA management system exists.=C2=A0
Due to such compromises, malicious ROAs may get = created,=C2=A0
AS prepend c= ount in BGPsec may be changed maliciously, or the route leak=C2=A0
protection (RLP) attribute in the r= oute leak solution may be maliciously altered.=C2=A0
We hope that such malicious activity is 1% or les= s of the attacks,=C2=A0
and= that we are successfully addressing the other 99% in our solution methods.= =C2=A0
I=E2=80=99ll add tex= t accordingly for EPF-uRPF/Algorithm A in the Security Considerations secti= on.=C2=A0

We all hope that malicious activity on the Internet is = kept to a minimum=E2=80=A6but that doesn=E2=80=99t mean that the risk doesn= =E2=80=99t exist, or that the effect of minimal activity will also be minim= al.=C2=A0 Not all prefixes are made the same: affecting just one could have= significant consequences.


>>>-------------------------= ---------------------------------------------=C2=A0
>>>COMMENT:=C2=A0
>>>=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=C2=A0=C2=A0<= /span>
>...=C2=A0
>= ;>>ASes in an ISP's customer cone SHOULD be used to augment the a= ppropriate RPF=C2=A0
>&g= t;>lists." How? Note that the Introduction already sets the stage b= y saying that=C2=A0
>>= ;>"the routes under consideration are assumed to have been vetted b= ased on prefix=C2=A0
>&g= t;>filtering [RFC7454] and possibly (in the future) origin validation [R= FC6811]."=C2=A0
>&g= t;>If ROAs SHOULD be used (=C2=A73.5), why is origin validation only &qu= ot;possibly (in the=C2=A0
&= gt;>>future)" considered (=C2=A71)? Maybe a better statement wou= ld be that "routes=C2=A0<= br>>>>SHOULD be validated using prefix filtering, origin validatio= n and IRR route=C2=A0
>&= gt;>objects".=C2=A0
>>=C2=A0
>>= ;We agree with your suggested rewording in Section 1. We=E2=80=99ll use tha= t.=C2=A0
>>What is ad= vised in Section 3.5 regarding ROAs is as follows.=C2=A0
>>In Figure 3, suppose that prefix P4 a= ROA with AS1,=C2=A0
>&g= t;and AS4 (ISP4) may not have received a route for P4 (on a given customer = interface).=C2=A0
>>B= ut AS4 (ISP4) has received (on that customer interface) a route for P1 with= =C2=A0
>>the same ori= gin AS (AS1) as in the ROA for P4.=C2= =A0
>>Then AS4 (ISP4) should augment its corresponding RPF = list with P4=C2=A0
>>= to allow the possibility that AS1 could legitimately announce=C2=A0
>>a route for P4 and potenti= ally use a SA (in a data packet) belonging in P4.=C2=A0=C2=A0
>>We'll add this explanation in Section 3.5.=C2=A0

>Hmm=E2=80=A6 Except that the= =E2=80=9Cpossibility=E2=80=9D that an announcement exists *and* the use as= a SA, is different from AS1 really doing it. IOW, augmenting with the expe= ctation that it may happen has its own risks=E2=80=A6=C2=A0
>= =C2=A0


Yep, there is that trade-off. Here we choose to fu= rther reduce the possibility=C2=A0
of false positive (for SA invalid) at the expense of some other ris= k.=C2=A0
Yes, a malicious a= ctor at another AS in the neighborhood=C2=A0
within the customer cone might take advantage to some ext= ent.=C2=A0
But the same vul= nerability exists even if the update were announced.=C2=A0=C2=A0

Yes=E2=80=A6but it is importan= t to clearly mention the known vulnerabilities of the solutions being propo= sed.


Thanks!

Alvaro.

--00000000000041b1af05908e3339-- From nobody Tue Aug 20 10:14:33 2019 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5160A120232; Tue, 20 Aug 2019 10:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 UyrB1e0fnu_C; Tue, 20 Aug 2019 10:14:29 -0700 (PDT) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2129.outbound.protection.outlook.com [40.107.91.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D88C212018D; Tue, 20 Aug 2019 10:14:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ff0YPQDgWOk3d0vZpI/DhLV3vQ6rfoG8wezmDpkkIlqizPjwjaWc7BeK/BSA9iutSLs55zf7LMIq33l9jdoYxW2oeStQ953UTciNXVd8QehauM4v0Exw7ul/pYGay6WOyE43UItExo7rCZ+yWcRjQzQ/I8A0QjP1ZIBj4pU/9T2xEP4GJ7+hmrdiCPKG+ZGYlINpfxSorrYLjmiF9S3pqhnEzgx5aamYoyuv6eGStuXpsT+nwnhsqpX/kVLfPl4eFb2K4dTYcGwM8WcYgER0SnHVNj5uBrGFNFfaVTyYRFpPQXCuxZ/BIYcozsACaQKENMjAbTbXRUYGsNpM3SrQ+w== 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=GgM6IHN1I1Dfva9gHMciwCdRHe71Pol0Ae5+GxemQxA=; b=KPvDGViuNP3/irGRnQlvW4jXYhRhbgN1GoGEptcsEb3Xp/PUXSjrZeEDDImOmiwit5r8wiwJnIkaGS4YNyrXbYb+G4hvfGeadUh89eEd4OfU0vDcTptKZ2R71LEvwbL+xeXWWfulT1V8PbBuOYENTB3HbvvQOp5Ox0UMSebr8qw5maqIeo6PAVUCBMXB7EGbZKYNH1lKZKH9aRbYi3EsTIRI2/h0Nrvu2DNr5npJviekW2mZrEeEL42aQuZnBO1x0ZYk9CIl1tXvYIfSjo3zb2cfs9hBviIJuMeUYXQ3WmHU2Kx0xj/n2UdcEPllKxnKrN+hjAMmlHQfcI4n3Q6aHw== 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=GgM6IHN1I1Dfva9gHMciwCdRHe71Pol0Ae5+GxemQxA=; b=I3inSkBcv1tlWiqeJ8A+LWAbeWnRR9PzQs+u5aL0qIcP0/0Tlj+IFoxp0ePUEiymcpPvDT36h+metU7jM6BhVQwoS7Oy+xxsViDoLuoYNytMex2sXyPnvIK2ulbBemo/ARpnUlzty4IUCSy30S7KglZVsefON0z2hwLFA7BLpoo= Received: from DM6PR09MB3019.namprd09.prod.outlook.com (20.178.2.203) by DM6PR09MB4011.namprd09.prod.outlook.com (10.141.166.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Tue, 20 Aug 2019 17:14:27 +0000 Received: from DM6PR09MB3019.namprd09.prod.outlook.com ([fe80::fc5a:9648:8e8f:7968]) by DM6PR09MB3019.namprd09.prod.outlook.com ([fe80::fc5a:9648:8e8f:7968%6]) with mapi id 15.20.2178.018; Tue, 20 Aug 2019 17:14:27 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Alvaro Retana , The IESG CC: "Murphy, Sandra" , Sandra Murphy , "draft-ietf-opsec-urpf-improvements@ietf.org" , Jen Linkova , "opsec@ietf.org" , "opsec-chairs@ietf.org" , Warren Kumari Thread-Topic: Alvaro Retana's Discuss on draft-ietf-opsec-urpf-improvements-03: (with DISCUSS and COMMENT) Thread-Index: AQHVVH41+WK2q56zSkaIVPY4TX30Q6cBbRMZgAGRGwCAARoHb4AAGHgAgAAaK2k= Date: Tue, 20 Aug 2019 17:14:27 +0000 Message-ID: References: <156599290421.23877.9763694862590191063.idtracker@ietfa.amsl.com> , In-Reply-To: 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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.223.129] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 33db428d-f6f2-423d-4ad3-08d72591db14 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DM6PR09MB4011; x-ms-traffictypediagnostic: DM6PR09MB4011: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 013568035E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(136003)(396003)(39860400002)(346002)(199004)(189003)(71190400001)(76176011)(229853002)(478600001)(14454004)(26005)(102836004)(5660300002)(53546011)(6506007)(33656002)(6246003)(6436002)(9686003)(561944003)(55016002)(66066001)(86362001)(446003)(476003)(186003)(7696005)(66574012)(7736002)(25786009)(11346002)(66556008)(305945005)(4326008)(74316002)(3846002)(91956017)(81156014)(81166006)(256004)(8676002)(14444005)(6116002)(99286004)(71200400001)(53936002)(2906002)(66446008)(64756008)(66946007)(76116006)(110136005)(66476007)(8936002)(54906003)(486006)(316002)(52536014)(87944003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR09MB4011; H:DM6PR09MB3019.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: WsPNhmopRYpMeKxEBsXtG6fk34VQxBgmq77eyzJet1wUicseg9wdIl61ihlxnRaalwn9bxQDL/KNvT2ZtwyQ+QX8YQyR126lZttgC5uZovE25KciHYAccoNdpc+fd21QH2cCGpYjFJN886dgxMg1stpAi9mr2u6vtCXhoXrmIGfMqkp/468bYIjKzEzmxo+3KzpWe15LQbAEfUd/Am0N4qSryLVKq6Y0k7IEzvi3SiwDHKl6hDta4JjL2Y/bLNpzyMHAXAZqr396Naj6CvfGj5wFZdrr9ic2N0mXOSDB6ZVzY8CiozUIvUgvpMOqSiS59r6bC9dxMbwL+a6v5mPFezJ+6RtNnnXFd+b9orFwXhf6+gNVIv5fg+uHpvporDSRUT50avFmbSyBjbeW7PW9Z8iKrZ5SA8F1QoXILfZRq2w= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 33db428d-f6f2-423d-4ad3-08d72591db14 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2019 17:14:27.0961 (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: HSDJ+fb3JPmoBK1zt9GmXVH7WvXBrBqyNv9sssHsGoRbvVnLPYHlcsGZk9SlJHYD3tzdnKeU0dw7ssJLexiXOA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR09MB4011 Archived-At: Subject: Re: [OPSEC] Alvaro Retana's Discuss on draft-ietf-opsec-urpf-improvements-03: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 17:14:31 -0000 Thank you, Alvaro. This has been a very helpful discussion. I'll update the draft following your recommendations/suggestions. I think I can upload a new version by tomorrow morning. Sriram ________________________________________ From: Alvaro Retana Sent: Tuesday, August 20, 2019 11:35 AM To: Sriram, Kotikalapudi (Fed); The IESG Cc: Murphy, Sandra; Sandra Murphy; draft-ietf-opsec-urpf-improvements@ietf.= org; Jen Linkova; opsec@ietf.org; opsec-chairs@ietf.org Subject: Re: Alvaro Retana's Discuss on draft-ietf-opsec-urpf-improvements-= 03: (with DISCUSS and COMMENT) On August 20, 2019 at 10:29:22 AM, Sriram, Kotikalapudi (Fed) (kotikalapudi= .sriram@nist.gov) wrote: Sriram: Hi! Let=92s cut to the chase=85 >>Of course, according to Section 3.7, if an ISP is uncertain that >>Algorithm A is applicable in their scenario, then they SHOULD apply Algor= ithm B. >True, but that still doesn=92t provide any tools for the ISP to know eithe= r way. If there=92s no way to know (other than trusting your neighbors) tha= t the network is not in the middle of a =93challenging scenario=94, then wh= y wouldn't Algorithm B always be used? Yes, it may end up being true that Algorithm B is always used. We also want to let ISPs make their own decision about applicability of Algorithm A. I am hoping for agreement on the proposed wording change in Section 3.7 (with modifications you may suggest). It may be just me=85in fact, I didn=92t find significant discussion about t= he applicability of the algorithms on the list, beyond the initial discussi= on of draft-sriram-opsec-urpf-improvements-00, where the =93challenging sce= nario=94 was introduced because (in my interpretation) the original proposa= l didn=92t address real deployments. Given that Algorithm B is more flexible, and that the limitations from Algo= rithm A are overcome (=A73.4), I would like to see B be the recommendation. I am ok if Algorithm A is mentioned as an alternative (not a recommendation= ); one that is less flexible and has specific limitations =97 even if those= limitations are not expected/assumed, the vulnerability to a change in con= ditions should be clearly spelled out. >>>Still looking at Figure 4, if the operator of ISP4 uses Algorithm A (bec= ause >>>he/she thinks they may not be in a "challenging scenario"), then it open= s the >>>door to ISP2 changing its policy so that the uRPF check in ISP4 fails, a= s shown >>>in Figure 4. IOW, an attacker in ISP2 could stop advertising reachabilit= y to >>>some prefixes and cause ISP4 to fail the uRPF check and drop the traffic= . The >>>victim in this case could be AS1, whose traffic (through ISP2 to ISP4) w= as >>>flowing fine and then it stopped. >> >>There are two observations that are in order here: >>1. An ISP would not normally drop its own paying customer=92s >>routes with malicious intent. >>2. It is also hard to envision that ISP2 would attack its upstream ISP4 >>(in Figure 4) just to disrupt its SAV (uRPF), while that results in >>absolutely no gain but only causes unreachability for >>its (ISP2=92s) own customer and self-inflicted loss of revenue/customers. >I also doubt that an operator would take actions to harm its own paying cu= stomers =97 but the routers can be compromised anyway...or the advertisemen= t can come from the customer itself with a NO_EXPORT community, etc.. The m= ain case I=92m thinking of is the compromised/rogue router. In any of those= cases, choosing Algorithm A opens the door to vulnerabilities. Yes, they m= ight be the same (or at least similar) as what exists with FP-uRPF =97 but = they are not mentioned. Even for other BGP security mechanisms, the issue of compromise of a router or RPKI/ROA management system exists. Due to such compromises, malicious ROAs may get created, AS prepend count in BGPsec may be changed maliciously, or the route leak protection (RLP) attribute in the route leak solution may be maliciously al= tered. We hope that such malicious activity is 1% or less of the attacks, and that we are successfully addressing the other 99% in our solution metho= ds. I=92ll add text accordingly for EPF-uRPF/Algorithm A in the Security Consid= erations section. We all hope that malicious activity on the Internet is kept to a minimum=85= but that doesn=92t mean that the risk doesn=92t exist, or that the effect o= f minimal activity will also be minimal. Not all prefixes are made the sam= e: affecting just one could have significant consequences. >>>---------------------------------------------------------------------- >>>COMMENT: >>>=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97= =97=97=97=97=97=97=97=97=97=97=97 >... >>>ASes in an ISP's customer cone SHOULD be used to augment the appropriate= RPF >>>lists." How? Note that the Introduction already sets the stage by saying= that >>>"the routes under consideration are assumed to have been vetted based on= prefix >>>filtering [RFC7454] and possibly (in the future) origin validation [RFC6= 811]." >>>If ROAs SHOULD be used (=A73.5), why is origin validation only "possibly= (in the >>>future)" considered (=A71)? Maybe a better statement would be that "rout= es >>>SHOULD be validated using prefix filtering, origin validation and IRR ro= ute >>>objects". >> >>We agree with your suggested rewording in Section 1. We=92ll use that. >>What is advised in Section 3.5 regarding ROAs is as follows. >>In Figure 3, suppose that prefix P4 a ROA with AS1, >>and AS4 (ISP4) may not have received a route for P4 (on a given customer = interface). >>But AS4 (ISP4) has received (on that customer interface) a route for P1 w= ith >>the same origin AS (AS1) as in the ROA for P4. >>Then AS4 (ISP4) should augment its corresponding RPF list with P4 >>to allow the possibility that AS1 could legitimately announce >>a route for P4 and potentially use a SA (in a data packet) belonging in P= 4. >>We'll add this explanation in Section 3.5. >Hmm=85 Except that the =93possibility=94 that an announcement exists *and*= the use as a SA, is different from AS1 really doing it. IOW, augmenting wi= th the expectation that it may happen has its own risks=85 > Yep, there is that trade-off. Here we choose to further reduce the possibil= ity of false positive (for SA invalid) at the expense of some other risk. Yes, a malicious actor at another AS in the neighborhood within the customer cone might take advantage to some extent. But the same vulnerability exists even if the update were announced. Yes=85but it is important to clearly mention the known vulnerabilities of t= he solutions being proposed. Thanks! Alvaro. From nobody Tue Aug 20 12:13:23 2019 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9096120A18; Tue, 20 Aug 2019 12:13:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-opsec-urpf-improvements@ietf.org, Sandra Murphy , opsec-chairs@ietf.org, sandy@tislabs.com, opsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <156632839487.394.4368131465284019480.idtracker@ietfa.amsl.com> Date: Tue, 20 Aug 2019 12:13:14 -0700 Archived-At: Subject: [OPSEC] Roman Danyliw's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 19:13:15 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-opsec-urpf-improvements-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsec-urpf-improvements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) I support Alvaro Retana’s DISCUSS point about the needed clarity on algorithm selection (A vs. B) and the security assumptions being made about Algorithm A. (2) Editorial -- Document header: s/Updates: RFC3704/Updates: 3704/ -- Section 2.1. Editorial. s/are maintained which list/are maintained to list/ From nobody Tue Aug 20 20:29:16 2019 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C2C120045; Tue, 20 Aug 2019 20:29:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-opsec-urpf-improvements@ietf.org, Sandra Murphy , opsec-chairs@ietf.org, sandy@tislabs.com, opsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <156635814815.378.5146142936311387167.idtracker@ietfa.amsl.com> Date: Tue, 20 Aug 2019 20:29:08 -0700 Archived-At: Subject: [OPSEC] Adam Roach's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 03:29:08 -0000 Adam Roach has entered the following ballot position for draft-ietf-opsec-urpf-improvements-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsec-urpf-improvements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for a clearly written document. My understanding of routing is pretty simplistic, and I still found the technique well-explained and easy to follow. This is no small feat. The one term I had to go searching for was "stub AS". If this is a generally known term, that's fine -- but if not, it may warrant a short definition or citation. --------------------------------------------------------------------------- §1.1: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. Please use the boilerplate from RFC 8174. --------------------------------------------------------------------------- §3.3: I believe I understand how the described Algorithm B, is applied by AS4, will result in acceptance of AS1's packets from AS2. I'm a bit lost, however, about the means by which AS2 will accept them such that they could be delivered to AS4. Is there an assumption that AS2 is employing an ACL-based approach? If so, this should probably be stated explicitly. (This might be implied by text elsewhere, in which case I apologize for my confusion; although it may still be worth explicitly explaining.) --------------------------------------------------------------------------- §3.5: > It is worth emphasizing that an indirect part of the proposal in the > draft is that RPF filters may be augmented from secondary sources. Nit: "the draft" won't age gracefully. I suggest changing to "this document" or somesuch. --------------------------------------------------------------------------- §3.6.1: > +---------------------------------+---------------------------------+ > | Very Large Global ISP | 32392 | > | ------------------------------- | ------------------------------- | > | Very Large Global ISP | 29528 | > | ------------------------------- | ------------------------------- | I suspect there was a transcription error copying these lines from the source material, as the appearance of two rows with identical labels seems unlikely to be intended. I skimmed the cited source material to see if I could figure out what happened here, but found neither of these numbers (nor any mention of "Mid-size Global ISP"), so I'm afraid I can't make a concrete suggestion for a fix. I did find that adding the numbers in the first column on slide 6 yielded 32393, which is tantalizingly close to the first number, but that might just be a coincidence. From nobody Wed Aug 21 03:13:12 2019 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38748120288; Wed, 21 Aug 2019 03:13:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Vigoureux via Datatracker To: "The IESG" Cc: draft-ietf-opsec-urpf-improvements@ietf.org, Sandra Murphy , opsec-chairs@ietf.org, sandy@tislabs.com, opsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Vigoureux Message-ID: <156638238422.25801.5282209588346224957.idtracker@ietfa.amsl.com> Date: Wed, 21 Aug 2019 03:13:04 -0700 Archived-At: Subject: [OPSEC] Martin Vigoureux's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 10:13:04 -0000 Martin Vigoureux has entered the following ballot position for draft-ietf-opsec-urpf-improvements-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsec-urpf-improvements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Ingress/egress Access Control Lists (ACLs) are maintained which list acceptable (or alternatively, unacceptable) prefixes for the source addresses in the incoming/outgoing Internet Protocol (IP) packets. the beginning of that sentence is a bit hard to parse, but maybe it's just for me. Any packet with a source address that does not match the filter is dropped. well, that really depend on the match criteria. If the list is of unacceptable addresses and you don't match on these, then you should forward the packet. Adj-RIB-Ins did you mean Adj-RIBs-In? Figures 1 and 2 claim that EFP-uRPF works best but it has still not been described at that stage so it is a bit difficult to understand that claim. From nobody Wed Aug 21 06:30:24 2019 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00A5120A7D; Wed, 21 Aug 2019 06:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=nokia.onmicrosoft.com 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 9wdi0RTr_Ve7; Wed, 21 Aug 2019 06:30:09 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on070d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::70d]) (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 B1203120A63; Wed, 21 Aug 2019 06:30:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FSMR7lbo0FhQOsbhsdSUWH7N8/eIyQeGpnutLk2QwiQWzZWrBhDrgDF3rLZHX3AsK66XnoJM98Or0o3bqpYez4XrcKJruPE0r48rutVlsyJKvOTPleSiQLJz/57a8Xu7BJUoIF1tHAhCdF4AxCjlgcDeVIiqEnPAzfbbyY5jL4ou9KfgkAXlp66A3kvLsMLo93jNjU38jzNFgDjAVWNJbARdzXPLDm6QtCAreQIvEOg1zPhsTQjfFSa3Rr1RpAiIzxxGV41IF3wrtZnLlG+++NC9UgTpo6z1fNvVonvM2fj3L6VX0XD2TDeWuJZig0QjUesY3KvZIKhTt2M4Ir5tkw== 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=bUvOJINsKwWIzGKewbGV8msYMbPx3EdLxnaHd6aEd/Q=; b=dlXwUqo40q0P0smJK3X78CqA2XOy/rWBBwbO1IxvcKpMFoI+GKQ80hXY+x0loggCx6HdVT2SiBBU0zL6NP/KrOd8COoSeQAX4wviAGqX6xo7D9CG+TwR/fXUYonSCUU3UlAmhHuBdR296E48B6i+Rcsi+9j2tYH7Vo8TiZ8RdilfkOgELzFz6BpWKA5+FHqHLUVD8qOm1x1dbL89gm5GXaGtsoWKgbOJKG1DSlPGmmg+CACKdI9AQo5Ehl00Q52OMO2buKyEhD9StADFXMVOtCLj4Hm5MBc3l8RCWZVEkoruKL+9a+Y7DFz1dpUIaF8FE9kvEHdZfPKpjC7X8E/fEA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bUvOJINsKwWIzGKewbGV8msYMbPx3EdLxnaHd6aEd/Q=; b=RmJMfzfmKU7m+bVP4UMDgBFZ7QNvalPQB/thvPLz/ZCBor5wZRdYT/kZf38NyBj/STNCi6YLLhH0sOXU+kewKtiLLW2hn/6NVn4f2pMoxcwfQq8TRwYKY/b0mkEqnBlgCx5h+gokrOlcf4PdRcirMvg+Qg3cDtYCKXmhnHcfwtI= Received: from DB7PR07MB4106.eurprd07.prod.outlook.com (52.134.103.159) by DB7PR07MB5093.eurprd07.prod.outlook.com (20.177.194.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.12; Wed, 21 Aug 2019 13:30:06 +0000 Received: from DB7PR07MB4106.eurprd07.prod.outlook.com ([fe80::3151:b68c:7099:3583]) by DB7PR07MB4106.eurprd07.prod.outlook.com ([fe80::3151:b68c:7099:3583%6]) with mapi id 15.20.2199.011; Wed, 21 Aug 2019 13:30:06 +0000 From: "Bocci, Matthew (Nokia - GB)" To: "rtg-ads@ietf.org" CC: "rtg-dir@ietf.org" , "opsec@ietf.org" , "draft-ietf-opsec-urpf-improvements@ietf.org" Thread-Topic: RtgDir review: draft-ietf-opsec-urpf-improvements03.txt Thread-Index: AQHVWCSLk+WxzCivaUqM/Uc+Pc7zTg== Date: Wed, 21 Aug 2019 13:30:05 +0000 Message-ID: <695D6B79-C68C-47FB-9950-CE50233E9BDC@nokia.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1c.0.190812 authentication-results: spf=none (sender IP is ) smtp.mailfrom=matthew.bocci@nokia.com; x-originating-ip: [81.108.178.133] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0d64aa5c-6153-47ef-17ee-08d7263bae0c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4618075)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7167020)(7193020); SRVR:DB7PR07MB5093; x-ms-traffictypediagnostic: DB7PR07MB5093: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0136C1DDA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(376002)(346002)(366004)(136003)(396003)(199004)(189003)(4326008)(6916009)(55236004)(2351001)(71200400001)(71190400001)(54906003)(450100002)(486006)(316002)(478600001)(5640700003)(33656002)(36756003)(26005)(58126008)(102836004)(6486002)(2616005)(6436002)(25786009)(86362001)(66066001)(476003)(9326002)(14454004)(186003)(14444005)(256004)(8936002)(5660300002)(66476007)(66556008)(8676002)(54896002)(81166006)(81156014)(66946007)(76116006)(2906002)(6306002)(99286004)(2501003)(7736002)(66446008)(53936002)(3846002)(6116002)(64756008)(91956017)(6512007)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB5093; H:DB7PR07MB4106.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 8EtK52wpSJsZDuIf81mcpJ9DTO1ZnQ7725lOWsS2yZhVaRAu76+2cmzxsfPXE9ChA5c3gEJ453cG0fZih9fgBjsIGUdE1wUNGDEF7Km8do+MSC9SuuSZE4pVjSB1E8RFurt4Uba8ajHu1/IRu+v9HN3yDmL53awda2cC51GybZsVFhZ28n7hmE8K+tO7/QHJLXX7Gzsajl16w7aafANeFvP65rpMkdtGcChPFAXGoJgYErA7DEoC0Jj+KwePsP5uffA5ryFx4gAPDbktQN+5KiglVhdPxGbHn0AQmQArCDLohKNXfEL9Y0qIf/6wch8aOH7PiKntv7WdWUdHWbyDy8wg0sSRivqOGFh7amNB0DEqNt+BQXTrlVVCVA5fBdY/WBrURAMe8wSqwc20V3faU5GVXMk8sIGEcaQ929AUpbY= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_695D6B79C68C47FB9950CE50233E9BDCnokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0d64aa5c-6153-47ef-17ee-08d7263bae0c X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2019 13:30:06.0399 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TcQDsLCqbwgtVEg8QMe7nv+HZQwk+MMpHFva/DjT94ZxBFPiSyYdSDHXvx37n/7uULNUqP1DV/oxy3vYitXH6Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5093 Archived-At: Subject: [OPSEC] RtgDir review: draft-ietf-opsec-urpf-improvements03.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 13:30:17 -0000 --_000_695D6B79C68C47FB9950CE50233E9BDCnokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0 byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMg b24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCg0KQWx0aG91Z2ggdGhlc2Ug Y29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0 IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBh bnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0 cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRo ZSBkcmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtb3BzZWMtdXJwZi1pbXByb3ZlbWVudHMw My50eHQNClJldmlld2VyOiBNYXR0aGV3IEJvY2NpDQpSZXZpZXcgRGF0ZTogMjEgQXVndXN0IDIw MTkNCkludGVuZGVkIFN0YXR1czogSW5mb3JtYXRpb25hbA0KDQpTdW1tYXJ5Og0KSSBoYXZlIHNv bWUgbWlub3IgY29uY2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxk IGJlIHJlc29sdmVkIGJlZm9yZSBwdWJsaWNhdGlvbi4NCg0KDQpDb21tZW50czoNCg0KR2VuZXJh bGx5LCBJIGZvdW5kIHRoZSBkcmFmdCBxdWl0ZSByZWFkYWJsZSwgd2l0aCBhIGNsZWFyIGV4cGxh bmF0aW9uIG9mIHRoZSBwcm9ibGVtIHN0YXRlbWVudHMgYW5kIHNvbHV0aW9ucyBhcyB3ZWxsDQph cyB0aGUgdHJhZGUtb2ZmcyBvbiB0aGUgaW1wbGVtZW50YXRpb24uIEhvd2V2ZXIsIEkgaGF2ZSBv bmUgbWlub3IgY29tbWVudCBhbmQgYSBuaXQuDQoNCk1ham9yIElzc3VlczoNCg0KTm8gbWFqb3Ig aXNzdWVzIGZvdW5kLg0KDQoNCk1pbm9yIElzc3VlczoNCg0KVGVybWlub2xvZ3k6IFRoZSBkb2N1 bWVudCBleHBhbmRzICd1UlBGJyBhcyAndW5pY2FzdCByZXZlcnNlIHBhdGggZmlsdGVyaW5nJy4g SG93ZXZlciwgSQ0KYmVsaWV2ZSB0aGF0IHVSUEYgY29tbW9ubHkgbWVhbnMgJ3VuaWNhc3QgcmV2 ZXJzZSBwYXRoIGZvcndhcmRpbmcnICAgKHNlZSBSRkMzNzA0IGFuZA0KbW9zdCB2ZW5kb3IgZG9j dW1lbnRhdGlvbikuICJJbmdyZXNzIGZpbHRlcmluZyIgaXMgdGhlIGdlbmVyYWwgY29uY2VwdCBh bmQgInJldmVyc2UgcGF0aA0KIGZvcndhcmRpbmciIHRoZSBzcGVjaWZpYyBhbGdvcml0aG0uIERp ZCB0aGUgYXV0aG9ycyBpbnRlbmQgdG8gdXNlIGEgbmV3IHRlcm0sIGFuZCBpZiBzbyB3aHk/DQoN Cg0KTml0czoNCg0KU2VjdGlvbiAyLjU6ICIuLi5zZXBhcmF0ZSBmcm9tIHRoZSBnbG9iYWwgUm91 dGluZyBJbmZvcm1hdGlvbiBCYXNlIChSSUIpIFtKdW5pcGVyXVtSRkM0MzY0XS4iDQpWUkZzIGFy ZSBzdXBwb3J0ZWQgYnkgbW9zdCB2ZW5kb3JzIHNvIEkgdGhpbmsgaXQgaXMgc3VmZmljaWVudCBq dXN0IHRvIHJlZmVyZW5jZSBSRkM0MzY0Lg0K --_000_695D6B79C68C47FB9950CE50233E9BDCnokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: <29A7314E275ADB498A56E129F598AEB1@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMiA2IDMgNSA0IDUgMiAzIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9z ZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBs aW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8sPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg aGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJldmlld2VyIGZv ciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byByZXZpZXcgYWxs IHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3MgdGhyb3VnaCBJ RVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24gc3BlY2lhbCBy ZXF1ZXN0Lg0KIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlkZSBhc3Npc3Rh bmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIFJv dXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5v cmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHRo b3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0 aW5nIEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBh bG9uZyB3aXRoIGFueSBvdGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNl aXZlLCBhbmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkg dXBkYXRpbmcNCiB0aGUgZHJhZnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvY3VtZW50OiBk cmFmdC1pZXRmLW9wc2VjLXVycGYtaW1wcm92ZW1lbnRzMDMudHh0PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5SZXZpZXdlcjogTWF0dGhldyBCb2NjaTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmV2aWV3IERhdGU6IDIxIEF1Z3VzdCAyMDE5IDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW50ZW5kZWQgU3RhdHVzOiBJbmZvcm1h dGlvbmFsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1bW1hcnk6IDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIHNvbWUgbWlub3IgY29uY2VybnMgYWJvdXQgdGhp cyBkb2N1bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxkIGJlIHJlc29sdmVkIGJlZm9yZSBwdWJsaWNh dGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Db21tZW50czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R2VuZXJh bGx5LCBJIGZvdW5kIHRoZSBkcmFmdCBxdWl0ZSByZWFkYWJsZSwgd2l0aCBhIGNsZWFyIGV4cGxh bmF0aW9uIG9mIHRoZSBwcm9ibGVtIHN0YXRlbWVudHMgYW5kIHNvbHV0aW9ucyBhcyB3ZWxsPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hcyB0aGUgdHJhZGUtb2ZmcyBvbiB0 aGUgaW1wbGVtZW50YXRpb24uIEhvd2V2ZXIsIEkgaGF2ZSBvbmUgbWlub3IgY29tbWVudCBhbmQg YSBuaXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1ham9yIElzc3Vlczo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Tm8gbWFqb3IgaXNzdWVzIGZvdW5kLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pbm9yIElzc3Vl czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGVybWlub2xvZ3k6IFRoZSBkb2N1bWVudCBleHBh bmRzICd1UlBGJyBhcyAndW5pY2FzdCByZXZlcnNlIHBhdGggZmlsdGVyaW5nJy4gSG93ZXZlciwg SQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5iZWxpZXZlIHRoYXQgdVJQ RiBjb21tb25seSBtZWFucyAndW5pY2FzdCByZXZlcnNlIHBhdGggZm9yd2FyZGluZycmbmJzcDsm bmJzcDsgKHNlZSBSRkMzNzA0IGFuZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+bW9zdCB2ZW5kb3IgZG9jdW1lbnRhdGlvbikuICZxdW90O0luZ3Jlc3MgZmlsdGVyaW5nJnF1 b3Q7IGlzIHRoZSBnZW5lcmFsIGNvbmNlcHQgYW5kICZxdW90O3JldmVyc2UgcGF0aA0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDtmb3J3YXJkaW5nJnF1b3Q7IHRo ZSBzcGVjaWZpYyBhbGdvcml0aG0uIERpZCB0aGUgYXV0aG9ycyBpbnRlbmQgdG8gdXNlIGEgbmV3 IHRlcm0sIGFuZCBpZiBzbyB3aHk/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tml0czo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+U2VjdGlvbiAyLjU6ICZxdW90Oy4uLnNlcGFyYXRlIGZyb20gdGhlIGdsb2JhbCBSb3V0 aW5nIEluZm9ybWF0aW9uIEJhc2UgKFJJQikgW0p1bmlwZXJdW1JGQzQzNjRdLiZxdW90OzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VlJGcyBhcmUgc3VwcG9ydGVkIGJ5IG1v c3QgdmVuZG9ycyBzbyBJIHRoaW5rIGl0IGlzIHN1ZmZpY2llbnQganVzdCB0byByZWZlcmVuY2Ug UkZDNDM2NC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_695D6B79C68C47FB9950CE50233E9BDCnokiacom_-- From nobody Wed Aug 21 07:24:37 2019 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D5312094B; Wed, 21 Aug 2019 07:24:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-opsec-urpf-improvements@ietf.org, Sandra Murphy , opsec-chairs@ietf.org, sandy@tislabs.com, opsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <156639747640.25777.13888707111707970209.idtracker@ietfa.amsl.com> Date: Wed, 21 Aug 2019 07:24:36 -0700 Archived-At: Subject: [OPSEC] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-opsec-urpf-improvements-03=3A_=28with_COMMENT=29?= X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 14:24:36 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-opsec-urpf-improvements-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsec-urpf-improvements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the hard work put into this extensive document which is usually well-written and easy to understand. Sriram, also please to see this document completing its path after starting in OPSEC years ago ;-) Nevertheless, I have a couple of easy-to-fix COMMENTs and NITs. Regards, -éric == COMMENTS == -- Abstract -- The abstract reads like 'promises' but not as a summary of the document. Is there any chance to add 2 lines summarizing the 'how' ? -- Section 1.1 -- I am sure that by now you know that you have to use RFC 8174 boilerplate ;-) -- Section 2.2 -- For completeness and symmetry with section 2.3, please explain which packets will be dropped. -- Section 2.3 -- Suggestion: define "RPF list" before first use (even if mostly obvious). Please define "lateral peer" and why it is different to any other "peer". -- Section 3.1 -- Please define the "cone" used in this section. First time that I ever read this term and the RIPE paper does not explain it either (of course I am not a routing expert). == NITS == -- Section 1 -- Beside the intro, this section also introduces some terminology wording. May I suggest to have a (sub)section about "terminology" ? -- Section 2.1 -- CMTS was introduced as an acronym but not DSLAM. From nobody Wed Aug 21 11:55:46 2019 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311ED1207FC; Wed, 21 Aug 2019 11:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net 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 eT43Mi_oM5cK; Wed, 21 Aug 2019 11:55:35 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 2BD15120046; Wed, 21 Aug 2019 11:55:35 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x7LIsbVJ009592; Wed, 21 Aug 2019 11:55:33 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=c2WyacXJJq8iX5yGGtWvZNdSOuet2DZZ6ZVQB7kfXSQ=; b=04JHSuu+vjtYh+g6q+qFVkYeRL8Kpide/wFqdAM6pBGLNpkXG1YMNq66cJx/YV5I6YiO cYonTgeRCzkwRNJu9rZ3UX2EN6paDLEPpc+9lR9rmAU8zap6iDyUiw0ZVkGNjSGF3K4h UkJOqMLM9RZW42GIxpUxCFhW/V1A/azkgoF2U+kn1SU1w0NWkkGAS54Kk7KKdmXAaT3d w0swD8VI7S/jF3jrGIfWmtJkv57F2v9ve51XamY3AQI02OcNm1Rc7y7+V/xSzIMWP+FP diDA44WV5jPOdMwNhjzP9z5Cxqzy2L3aPNkMquyR1XELH2ZQYuVicpwwnxZmwZalnSSs cA== Received: from nam04-bn3-obe.outbound.protection.outlook.com (mail-bn3nam04lp2056.outbound.protection.outlook.com [104.47.46.56]) by mx0a-00273201.pphosted.com with ESMTP id 2uhb8s81ey-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 21 Aug 2019 11:55:33 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=it+HFvzBUlromSELzWwo1miHjmerqtX5SRHeYtTvYGMW5oSCDVSsdYl1KHze92nnkxkD8mtkbIePDTWm5TqGr/11PYYOhvfxIdIfLhRB5tOIAi2UlaisaidhjsjGG7vYlbTF5v7xwQYgc1QsgWj54RNVrB9lXuQala0e9beamiAEkMXGS53RoiZIlAV2TiL38k+3cMSYOY1BOXrP3j14bhHAvF+9BnaNj4MjLJzSJSJ0jRO+uRvJE2csJC17VFq0fePEBSsPOwNbpjQQYlcx8dSf4HX/72x6srvrkyY/11PlRCj0FFZaKPkgOeFxlSVrFA6+MykgT1ukKFjQV2wM5A== 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=c2WyacXJJq8iX5yGGtWvZNdSOuet2DZZ6ZVQB7kfXSQ=; b=VIn3vrEgi9zfSGPZsoVKq+PWeJ7CbV1DcmkVsSYdYiz3wTIxeMP5VRC0/pEc3SCWkm99SdHkxkdiBX5N1KWB9k4YOBXcVa4qz8UOcBDCDwJ+10CKSQBtHsYDKsSlqpI7lPqhaG+OTS09B0N5XgVq7zbqqxf05ZHQifMTy/ldAyzCsK9uh4nt2IS/fw9b2jGyIlYKKaX7UuuN7+soRsVbUe3ik/artvC/9mUeu7yunP4bFYm2/nqeCG5RhWzCpKqJA82yGAHaTOvWszQlQ+i+x/dCfU5cLvraiMvOP9utJmBgDIaH6QdCFhKSQDyZi9/oQWKP2BTurhGui+NduGo5wQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none Received: from MN2PR05MB6974.namprd05.prod.outlook.com (52.135.39.23) by MN2PR05MB5998.namprd05.prod.outlook.com (20.178.241.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Wed, 21 Aug 2019 18:55:30 +0000 Received: from MN2PR05MB6974.namprd05.prod.outlook.com ([fe80::dc18:4e26:f427:61c0]) by MN2PR05MB6974.namprd05.prod.outlook.com ([fe80::dc18:4e26:f427:61c0%2]) with mapi id 15.20.2199.011; Wed, 21 Aug 2019 18:55:30 +0000 From: Jeff Haas To: Adam Roach CC: The IESG , "draft-ietf-opsec-urpf-improvements@ietf.org" , Sandra Murphy , "opsec-chairs@ietf.org" , "opsec@ietf.org" Thread-Topic: Adam Roach's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT) Thread-Index: AQHVWFIBLZHiDMTq806gj602uQdV4A== Date: Wed, 21 Aug 2019 18:55:30 +0000 Message-ID: <34D21924-BA31-40D3-BCE5-38DE72033027@juniper.net> References: <156635814815.378.5146142936311387167.idtracker@ietfa.amsl.com> In-Reply-To: <156635814815.378.5146142936311387167.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6ad6f5d3-deb5-4f7c-c6a2-08d7266923aa x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:MN2PR05MB5998; x-ms-traffictypediagnostic: MN2PR05MB5998: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0136C1DDA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(396003)(136003)(366004)(39860400002)(346002)(199004)(189003)(6916009)(6512007)(561944003)(99286004)(53936002)(6246003)(229853002)(6436002)(33656002)(6486002)(14454004)(25786009)(4326008)(478600001)(86362001)(66066001)(54906003)(316002)(76176011)(102836004)(53546011)(6506007)(186003)(486006)(476003)(2616005)(11346002)(446003)(91956017)(3846002)(64756008)(76116006)(36756003)(66556008)(6116002)(66446008)(66946007)(66476007)(256004)(14444005)(5660300002)(8676002)(8936002)(7736002)(305945005)(81166006)(26005)(81156014)(2906002)(71200400001)(71190400001); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR05MB5998; H:MN2PR05MB6974.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: SSz7buuxcvUECil/9uu/nzA0wUjbKNN38jWmKfA9y25aKaCx6Tg6LuQrTbRVI0EQNsJEoOtSrWrlu4yEYmDzOUrZL/skYEH27ktw9TW+j7wk557r+zjieb83zdqygp5gNec5O/V1pz4UaSxqYNmfqUm8h8jBvKP6Vg4xYktyCOQms9sZwxk0yywef02FZ11WTTGN/UzoD0Wlhz8akiMWH77a1go/HzCM0GhNjgqaXSzHw4+gDVv+1cADQn7KAaqqsr5MHUWnDxjhFgIswoOPJqZi5JvgcvDqTG++9CkxMnH37EZZhycZNf7U4IEd2Di9e61O+wnbvNZ17YnL934s80jzs9a8JhTECmcqU5NOe5fSnhtuWrR2V9Z7Ql9747w7GJKE2vTyFWO0KuRUHkEhHP2eDSIS8mFTLGGmhtsL1sw= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 6ad6f5d3-deb5-4f7c-c6a2-08d7266923aa X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2019 18:55:30.6589 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UPMmfJv+z6lXg8w1K3Byb9Oog2c7TGzXpGCNak2f9pr0SjsbWssjEGCyHzVAvCwsknpo42Y3cpQUveDPWtJNyw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB5998 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-08-21_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=586 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908210183 Archived-At: Subject: Re: [OPSEC] Adam Roach's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 18:55:38 -0000 QWRhbSwNCg0KPiBPbiBBdWcgMjAsIDIwMTksIGF0IDIzOjI5LCBBZGFtIFJvYWNoIHZpYSBEYXRh dHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZz4gd3JvdGU6DQo+IA0KPiDCpzMuMzoNCj4gDQo+IEkg YmVsaWV2ZSBJIHVuZGVyc3RhbmQgaG93IHRoZSBkZXNjcmliZWQgQWxnb3JpdGhtIEIsIGlzIGFw cGxpZWQgYnkgQVM0LCB3aWxsDQo+IHJlc3VsdCBpbiBhY2NlcHRhbmNlIG9mIEFTMSdzIHBhY2tl dHMgZnJvbSBBUzIuIEknbSBhIGJpdCBsb3N0LCBob3dldmVyLCBhYm91dA0KPiB0aGUgbWVhbnMg Ynkgd2hpY2ggQVMyIHdpbGwgYWNjZXB0IHRoZW0gc3VjaCB0aGF0IHRoZXkgY291bGQgYmUgZGVs aXZlcmVkIHRvDQo+IEFTNC4gIElzIHRoZXJlIGFuIGFzc3VtcHRpb24gdGhhdCBBUzIgaXMgZW1w bG95aW5nIGFuIEFDTC1iYXNlZCBhcHByb2FjaD8gSWYNCj4gc28sIHRoaXMgc2hvdWxkIHByb2Jh Ymx5IGJlIHN0YXRlZCBleHBsaWNpdGx5LiAoVGhpcyBtaWdodCBiZSBpbXBsaWVkIGJ5IHRleHQN Cj4gZWxzZXdoZXJlLCBpbiB3aGljaCBjYXNlIEkgYXBvbG9naXplIGZvciBteSBjb25mdXNpb247 IGFsdGhvdWdoIGl0IG1heSBzdGlsbCBiZQ0KPiB3b3J0aCBleHBsaWNpdGx5IGV4cGxhaW5pbmcu KQ0KDQpGb3IgdGhlIGV4YW1wbGVzLCBpdCdzIG5vdCBpbXBvcnRhbnQgd2hldGhlciBBUzIgb3Ig QVMzIGFyZSBmaWx0ZXJpbmcuICBIb3dldmVyLCBldmVuIGlmIHRoZXkgYXJlLCB0aGVyZSdzIHN1 ZmZpY2llbnQgaW5mb3JtYXRpb24gaW4gdGhlIHJvdXRpbmcgZm9yIGl0IHRvIHdvcmsuDQoNCkJH UCBOT19FWFBPUlQgY29tbXVuaXR5IG1lYW5zIHRoYXQgcm91dGVzIHJlY2VpdmVkIGZyb20gQVMx IGF0IEFTMiBhcmUgbm90IHByb3BhZ2F0ZWQgdG8gQVM0LiAgU28sIHdlIGNhbiB1c2Ugb25lIG9m IHRoZSByb3V0aW5nIGJhc2VkIG1lY2hhbmlzbXMuDQoNCkJHUCBkb2VzIGhhdmUgYW4gYWRkaXRp b25hbCBjb21tdW5pdHksIE5PX0FEVkVSVElTRSB0aGF0IHdvdWxkbid0IHdvcmsgd2VsbCBmb3Ig dGhpcyBleGFtcGxlLiAgVGhpcyB3b3VsZCBwcmV2ZW50IHByb3BhZ2F0aW9uIG9mIFAxLFAyIHRv IG90aGVyIHJvdXRlcnMgaW4gQVMyLiAgSG93ZXZlciwgZXZlbiB0aGF0IG1heSBiZSBmaW5lIGRl cGVuZGluZyBvbiB3aGVyZSB1UlBGIGlzIGFwcGxpZWQ7IHR5cGljYWxseSB0aGF0J3Mgb25seSBB UyBib3JkZXIgcm91dGVycy4NCg0KDQoNCg0KDQoNCg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+IA0KPiDCpzMuNToNCj4gDQo+PiBJdCBpcyB3b3J0aCBlbXBoYXNpemluZyB0aGF0IGFuIGlu ZGlyZWN0IHBhcnQgb2YgdGhlIHByb3Bvc2FsIGluIHRoZQ0KPj4gZHJhZnQgaXMgdGhhdCBSUEYg ZmlsdGVycyBtYXkgYmUgYXVnbWVudGVkIGZyb20gc2Vjb25kYXJ5IHNvdXJjZXMuDQo+IA0KPiBO aXQ6ICJ0aGUgZHJhZnQiIHdvbid0IGFnZSBncmFjZWZ1bGx5LiBJIHN1Z2dlc3QgY2hhbmdpbmcg dG8gInRoaXMgZG9jdW1lbnQiDQo+IG9yIHNvbWVzdWNoLg0KPiANCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+IA0KPiDCpzMuNi4xOg0KPiANCj4+ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4gfCBWZXJ5IExhcmdl IEdsb2JhbCBJU1AgICAgICAgICAgIHwgMzIzOTIgICAgICAgICAgICAgICAgICAgICAgICAgICB8 DQo+PiB8IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gfCAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tIHwNCj4+IHwgVmVyeSBMYXJnZSBHbG9iYWwgSVNQICAgICAgICAgICB8 IDI5NTI4ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPj4gfCAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tIHwgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSB8DQo+IA0K PiBJIHN1c3BlY3QgdGhlcmUgd2FzIGEgdHJhbnNjcmlwdGlvbiBlcnJvciBjb3B5aW5nIHRoZXNl IGxpbmVzIGZyb20gdGhlIHNvdXJjZQ0KPiBtYXRlcmlhbCwgYXMgdGhlIGFwcGVhcmFuY2Ugb2Yg dHdvIHJvd3Mgd2l0aCBpZGVudGljYWwgbGFiZWxzIHNlZW1zIHVubGlrZWx5DQo+IHRvIGJlIGlu dGVuZGVkLiBJIHNraW1tZWQgdGhlIGNpdGVkIHNvdXJjZSBtYXRlcmlhbCB0byBzZWUgaWYgSSBj b3VsZCBmaWd1cmUNCj4gb3V0IHdoYXQgaGFwcGVuZWQgaGVyZSwgYnV0IGZvdW5kIG5laXRoZXIg b2YgdGhlc2UgbnVtYmVycyAobm9yIGFueSBtZW50aW9uIG9mDQo+ICJNaWQtc2l6ZSBHbG9iYWwg SVNQIiksIHNvIEknbSBhZnJhaWQgSSBjYW4ndCBtYWtlIGEgY29uY3JldGUgc3VnZ2VzdGlvbiBm b3IgYQ0KPiBmaXguIEkgZGlkIGZpbmQgdGhhdCBhZGRpbmcgdGhlIG51bWJlcnMgaW4gdGhlIGZp cnN0IGNvbHVtbiBvbiBzbGlkZSA2DQo+IHlpZWxkZWQgMzIzOTMsIHdoaWNoIGlzIHRhbnRhbGl6 aW5nbHkgY2xvc2UgdG8gdGhlIGZpcnN0IG51bWJlciwgYnV0IHRoYXQNCj4gbWlnaHQganVzdCBi ZSBhIGNvaW5jaWRlbmNlLg0KDQpJIGJlbGlldmUgYSBwcm9wZXIgcmVhZGluZyBvZiB0aGlzIGlz IHRoYXQgZWFjaCByb3cgaXMgYSBkaXN0aW5jdCBzZXJ2aWNlIHByb3ZpZGVyLiAgUGVyaGFwcyB1 cGRhdGluZyB0aGUgbGFiZWxpbmcgdG8gVmVyeSBMYXJnZSBHbG9iYWwgSVNQMS8yIHdvdWxkIGJl IGhlbHBmdWw/DQoNCi0tIEplZmYNCg0K From nobody Wed Aug 21 15:45:51 2019 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A829D120110; Wed, 21 Aug 2019 15:45:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-opsec-urpf-improvements@ietf.org, Sandra Murphy , opsec-chairs@ietf.org, sandy@tislabs.com, opsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156642754067.25756.14564875013672898583.idtracker@ietfa.amsl.com> Date: Wed, 21 Aug 2019 15:45:40 -0700 Archived-At: Subject: [OPSEC] Benjamin Kaduk's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 22:45:41 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-opsec-urpf-improvements-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsec-urpf-improvements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this well-written document! It will be beneficial to the security of the internet as a whole to have effective BCP38 protections applied more widely. I'm happy to see the discussion about Algorithm A vs. B as recommended default, prompted by Alvaro's ballot position. On the face of things I do share his concern, as having "safe defaults" in the sense of not dropping legitimate traffic seems pretty compelling, but I do recognize that Algorithm A produces a stricter check, and that is in a different sense "more safe". I don't think I have much to add to the discussion, though, so I'll continue to watch it play out. (Perhaps some of the discussion could make it into the security considerations of this document once things get settled, though.) Section 2.1 dropped. The ACLs for the ingress/egress filters need to be maintained to keep them up to date. Updating the ACLs is an operator driven manual process, and hence operationally difficult or infeasible. nit: hyphenate "operator-driven" Section 2.2 In Figure 1, I'm having a hard time understanding why feasible-path uRPF fails for case (2). Or is the intent of the caption and terminology note from above only to say that it fails for at least one of the enumerated cases? (On the other hand, there's a decent chance that the lack of comprehension is entirely on my end...) Section 2.3 can be described as follows. In Scenario 2 (described above, illustrated in Figure 2), it is possible that the second transit provider (ISP-b or AS3) does not propagate the prepended route for prefix P1 to the first transit provider (ISP-a or AS2). This is because AS3's decision policy permits giving priority to a shorter route to prefix P1 via a lateral peer (AS2) over a longer route learned directly from the customer (AS1). In such a scenario, AS3 would not send any route announcement for prefix P1 to AS2 (over the I expect this is just my lack of familiarity here, but does the decision policy "giving priority" to shorter routes vs customer routes mean that it won't propagate the customer advertisement at all or just that it won't route traffic that way? Section 3.2 o Additionally, from the routes it has learned from customers, a non-stub AS SHOULD announce at least one route per origin AS to each of its transit provider ASes. What are the security consequences of this? If, say, an AS only get very specific prefixes with very short paths from a customer and is now "forced" to advertise at least one of them by these practices, can that have a negative impact on routing? Would prepending itself in the path be a usable mitigation? Section 3.4 nit: there's perhaps room for harmonization of language between step (3) here and step (1) of Algorithm A. 4. Create the set of all unique prefixes for which routes exist in Adj-RIB-Ins of all lateral peer and transit provider interfaces Is the intention that "lateral peer and transiti provider interfaces" is equivalent to "all interfaces that are not directly-connected customer interfaces"? Section 3.6.1 The techniques described in this document require that there should be additional memory (i.e., TCAM) available to store the RPF lists in nit: TCAM isn't listed as "well-known" at https://www.rfc-editor.org/materials/abbrev.expansion.txt , so we probably have to expand it. The following table shows the measured customer cone sizes for various types of ISPs [sriram-ripe63]: The table contents make it seem like these are not "per-type" data, but rather specific data from hopefully representative samples. In particular... +---------------------------------+---------------------------------+ | Type of ISP | Measured Customer Cone Size in | | | # Prefixes (in turn this is an | | | estimate for RPF list size on | | | line card) | +---------------------------------+---------------------------------+ | Very Large Global ISP | 32392 | | ------------------------------- | ------------------------------- | | Very Large Global ISP | 29528 | ... perhaps these should be #1 and #2 to disambiguate. Section 3.7 * In general, loose uRPF method for SAV SHOULD be applied on lateral peer and transit provider interfaces. However, for lateral peer interfaces, in some cases an operator MAY apply EFP-uRPF method with Algorithm A if they deem it suitable. Since step (1) of Algorithm A explicitly says "of customer interfaces", we probably need a little bit more text here to say what it means to use Algorithm A for lateral peer and/or transit provider interfaces. (Or, perhaps, some reworking of the text describing Algorithm A, but that seems like a more invasive change. Section 4 This is rather related to Alvaro's Discuss, but how is an AS operator to know what type of peer and the nature of customer cone scenario that applies to a given case? Also, is there a way to know what the probability of dropping legitimate data packets is other than experimenting and waiting for customer complaints? (I guess it's probably okay, given the references, to not bother explicitly saying "erroneously dropping legitimate packets is bad".) From nobody Wed Aug 21 15:45:59 2019 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A948120129; Wed, 21 Aug 2019 15:45:44 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 xmyZ_ImA5Vqg; Wed, 21 Aug 2019 15:45:41 -0700 (PDT) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2102.outbound.protection.outlook.com [40.107.89.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E227120131; Wed, 21 Aug 2019 15:45:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kz/XF/rc3/3iIBJHfFELfcRKb1Itn6rnyrY8wsIP7WqO9jTGPaHe55gQkOCLRtaN8Z3LaLVcnZJ2oOzRBaEh0XlPLnWx7dCJo7zSnT54foTgG1M1grfkdCax1bnXqAJkEwc37jYofEEfmkUxdqhSUF5yhNuyxbAqshJhyz4N9D1J5RGCUwOUSVEsJsNg4AnDcBDtmc+REFnjWp0Wu5LDiMXqiAmu3A7Kt6GRIz/Anl+aEU0pnikNqgUhXLjAbszT3RUd3fRftysdodDRUQroTx/y5cTakRW1TC008+0iQWr6jGGyoz+vM7hTXXEeHuxm2FZR+Zyf5U+aialEB3yqzg== 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=21pQhcfaudFvAR1XE0d0zH9UyENMts/4yc2jjJFKrK0=; b=OqiNaq5t0D9RJTkPcgoIVd3I1Sc2Gfa2Eo/E4CQ2+3MXzUknS02LGzumqpBD0DJJGoH77PAf54kPBh6mmZ1L8L5MJAacNAhM5X71rz3/vGDVzBHyVlOj3jSfTny/zwrB5c5pgabXkl+xopQKFmlTWpk+zYYwwRMp1sn9O0LWc4VWvWi6IU2DA5ne4WAhdDRc/Wl+/BGXHDBKZt4z6sXVhFyp5alNEaMS7S0hO9TJQjVXHW6AkQHArdUHbbXLA315WKuvWT3qXUnHn+6jzsbRP1LFos6kYvx35848aMAXbzZip0smX3qD6AHxxuGtw+IWqKMAxzGGZXOozSA9h3kaYw== 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=21pQhcfaudFvAR1XE0d0zH9UyENMts/4yc2jjJFKrK0=; b=zOqdxtgG9me9NUzxyTS3r5CNCgQLpBV4/j4v3KUR63HqKk8nzoGeC7Yr4ZdTGPNc1MyD+QuIile6mAR6NEgPWd7T6KlGoayh4asJMyWPhRTrM4V+M8B5g/Vye/pkwRbbLqqrJwBmEaI5NiiR+cIydjVVWbjz9wKBdGDOh1gGELI= Received: from DM6PR09MB3019.namprd09.prod.outlook.com (20.178.2.203) by DM6PR09MB2874.namprd09.prod.outlook.com (20.176.95.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.18; Wed, 21 Aug 2019 22:45:39 +0000 Received: from DM6PR09MB3019.namprd09.prod.outlook.com ([fe80::fc5a:9648:8e8f:7968]) by DM6PR09MB3019.namprd09.prod.outlook.com ([fe80::fc5a:9648:8e8f:7968%6]) with mapi id 15.20.2178.018; Wed, 21 Aug 2019 22:45:39 +0000 From: "Sriram, Kotikalapudi (Fed)" To: The IESG , Adam Roach CC: "draft-ietf-opsec-urpf-improvements@ietf.org" , Sandra Murphy , "opsec-chairs@ietf.org" , Sandra Murphy , "opsec@ietf.org" Thread-Topic: Adam Roach's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT) Thread-Index: AQHVV9Cbx0ns/H85m0mFsQRubg2h5qcGKWpd Date: Wed, 21 Aug 2019 22:45:39 +0000 Message-ID: References: <156635814815.378.5146142936311387167.idtracker@ietfa.amsl.com> In-Reply-To: <156635814815.378.5146142936311387167.idtracker@ietfa.amsl.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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.220.124] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 35c6bd8e-8d87-4060-2fc0-08d726894a3b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DM6PR09MB2874; x-ms-traffictypediagnostic: DM6PR09MB2874: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0136C1DDA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(396003)(346002)(136003)(39860400002)(51914003)(189003)(199004)(86362001)(11346002)(66066001)(8936002)(102836004)(446003)(486006)(305945005)(316002)(6506007)(99286004)(76176011)(33656002)(71200400001)(71190400001)(256004)(14444005)(476003)(26005)(81166006)(81156014)(186003)(7736002)(8676002)(52536014)(110136005)(5660300002)(54906003)(9686003)(55016002)(3846002)(6246003)(66946007)(25786009)(66476007)(66556008)(64756008)(66446008)(6116002)(561944003)(14454004)(2906002)(478600001)(6436002)(76116006)(74316002)(53936002)(91956017)(7696005)(229853002)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR09MB2874; H:DM6PR09MB3019.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: uCwnVhhSMNTEG/vAUsFooajv42VujaTp8UOfp8dNRpEbuDRXlnIapn1934uLqujfq89MACDSOPi7B+pDNYlW5AXWcWfmNeR7uXvD1oyie932UgAkGl09k8BqotohzWMNizS9hY1Eo0omHE9z4JOSRzThqF9fPC6AGPqONQsHx+0Va/ZxS53uWAVwnAOMbE+bJTjzCgJAwWA2pPFrLJNmVayycF0bk3UyHAU6qUGr/YLXFVQP4R0HlHEHfseErRWGw3WmyYiAloYok8XWofF7Q/DYS31xZJrnmWeAhqUK8ZYx0JiuuzZfAnXI1akIDa3yzTF+YwBNprlYeW/RTSWb86oK8XajLmxYWGR2vh9hkunwRYUG+XKHvaVMyrwFpf66jVG4dsYZyOX0PLr2qcW3zZyspW2kyP/iBiEySyYGYwY= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 35c6bd8e-8d87-4060-2fc0-08d726894a3b X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2019 22:45:39.2203 (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: hul40AU+rbZevIlLZ1bQySRi6BOWayphOD6Zdkno7HUvVRA/uMgd8SN59pqTWWK0Q2cb0k1qogurWW/Zl/vn8w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR09MB2874 Archived-At: Subject: Re: [OPSEC] Adam Roach's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 22:45:48 -0000 Hi Adam, Thank you for the comments. >Thanks for a clearly written document. ..... Thank you. Nice of you. >The one term I had to go searching for was "stub AS". .... I have defined stub AS in my author's draft for the next version. Done. >.... Please use the boilerplate from RFC 8174. Yes, done. > =A73.3: >I believe I understand how the described Algorithm B, is applied by AS4, .= .... I think Jeff has addressed this quite well. Please let us know if you've fu= rther questions. > .... Nit: "the draft" won't age gracefully. I suggest changing to "this d= ocument" or somesuch. Yes. Now the sentence has "this document". >=A73.6.1: > +---------------------------------+---------------------------------+ > | Very Large Global ISP | 32392 | > | ------------------------------- | ------------------------------- | > | Very Large Global ISP | 29528 | > | ------------------------------- | ------------------------------- | >.... > ... I did find that adding the numbers in the first column on slide 6 >yielded 32393, which is tantalizingly close to the first number, but that >might just be a coincidence. ... You guessed it right where 32392 came from. And your math is better than ours :) 32393 is the correct number. Like Jeff has observed already, each line in the table corresponds to a unique ISP; so those first two lines in the table now read: > +---------------------------------+---------------------------------+ > | Very Large Global ISP X | 32393 | > | ------------------------------- | ------------------------------- | > | Very Large Global ISP Y | 29528 | > | ------------------------------- | ------------------------------- | Thanks for the catch. I've updated the draft accordingly. (I have not made any comments inline below.) Sriram ---------------------------- ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for a clearly written document. My understanding of routing is prett= y simplistic, and I still found the technique well-explained and easy to foll= ow. This is no small feat. The one term I had to go searching for was "stub AS"= . If this is a generally known term, that's fine -- but if not, it may warrant a short definition or citation. --------------------------------------------------------------------------- =A71.1: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. Please use the boilerplate from RFC 8174. --------------------------------------------------------------------------- =A73.3: I believe I understand how the described Algorithm B, is applied by AS4, wi= ll result in acceptance of AS1's packets from AS2. I'm a bit lost, however, ab= out the means by which AS2 will accept them such that they could be delivered t= o AS4. Is there an assumption that AS2 is employing an ACL-based approach? I= f so, this should probably be stated explicitly. (This might be implied by te= xt elsewhere, in which case I apologize for my confusion; although it may stil= l be worth explicitly explaining.) --------------------------------------------------------------------------- =A73.5: > It is worth emphasizing that an indirect part of the proposal in the > draft is that RPF filters may be augmented from secondary sources. Nit: "the draft" won't age gracefully. I suggest changing to "this document= " or somesuch. --------------------------------------------------------------------------- =A73.6.1: > +---------------------------------+---------------------------------+ > | Very Large Global ISP | 32392 | > | ------------------------------- | ------------------------------- | > | Very Large Global ISP | 29528 | > | ------------------------------- | ------------------------------- | I suspect there was a transcription error copying these lines from the sour= ce material, as the appearance of two rows with identical labels seems unlikel= y to be intended. I skimmed the cited source material to see if I could figur= e out what happened here, but found neither of these numbers (nor any mention= of "Mid-size Global ISP"), so I'm afraid I can't make a concrete suggestion fo= r a fix. I did find that adding the numbers in the first column on slide 6 yielded 32393, which is tantalizingly close to the first number, but that might just be a coincidence. From nobody Wed Aug 21 16:21:36 2019 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C79120100; Wed, 21 Aug 2019 16:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 9AlXcNoc9k8Q; Wed, 21 Aug 2019 16:21:25 -0700 (PDT) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2125.outbound.protection.outlook.com [40.107.91.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12EE312004C; Wed, 21 Aug 2019 16:21:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=erd5QjBULLWQkU7THalu8e2lzWHiMZs+P8OsFNRJxaGQpaj5QjJLw2msT2vThE1Lxb6JGVSKjFvNBK92txHk1FNYJm6jC2Gc2b3kc7rySXz/5FpShReio7E+CX7ZP5eRRLbZo82NXNhuti7zvIrwkfPHb++8i+pLTsMnpHEuHP8ZM8H7IiSmnj6Kkwi5YY/Yia8iPlrD+caoBYDjyoBMwydFg7R+oTje2Wi9/AAEqe7fL7DPU/5MowAivul348dSf44g5SdF2ag1zyrt7DTJsT3BN1gAj8Y10GIY9ZnRibQFi29/b8C0pn7H0dB3LX+FYwMG0CpLGliYBGeNLhaPOw== 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=bsWwYl0PzUFH4YxquoZ2QD58WBAPsy0ElRVOAyHyJ8Y=; b=VJujqevp05/MGH7MEcTPUurwvUV0y86AuIPOeb1EWwXvGC+/oFoqHxT4ldiNxFhE4Nwws7hSHQlwqcl4ICXXDQT4pg4ZRtibcu1ALK8yckDNkQGfZ+aKahQVf0Yx3MsMvAq40KrlmZ9ZKWCtJaby2AUnWQuaLQTl2BKgHAPPzeQ2uxRhCr2ZBCKjhB5ER8q8HLufnjNbU444HExmWkEjFN6w8IH1IiuYanVdtzud0C9P3kfuI1TPRx1oUlJEdmp7JjyCsIKImdeptER59wK9CEVTxSnBnApt3/VgEjZC/owmO3V9DxDHWc+xg3bx8LdEV+1tFEaB2mSxmpMpWuyBhg== 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=bsWwYl0PzUFH4YxquoZ2QD58WBAPsy0ElRVOAyHyJ8Y=; b=hdlJphZSnWe9v2r9tRZwmDX2ugt7XLHdGqAlisG6jNYwFcdoYYEagobqksR9q1zzm9hAjPGlmAVfXOe8oFmW2SGy9ahbb70IZM+W5LowO3hcimIQGsu/xovI5+jdZiG1c6s1jooZUYX/X1/H5jFMHavAxoPuALGFMlDrwVmIjSk= Received: from DM6PR09MB3019.namprd09.prod.outlook.com (20.178.2.203) by DM6PR09MB4413.namprd09.prod.outlook.com (20.179.226.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Wed, 21 Aug 2019 23:21:23 +0000 Received: from DM6PR09MB3019.namprd09.prod.outlook.com ([fe80::fc5a:9648:8e8f:7968]) by DM6PR09MB3019.namprd09.prod.outlook.com ([fe80::fc5a:9648:8e8f:7968%6]) with mapi id 15.20.2178.018; Wed, 21 Aug 2019 23:21:23 +0000 From: "Sriram, Kotikalapudi (Fed)" To: The IESG , Roman Danyliw CC: "draft-ietf-opsec-urpf-improvements@ietf.org" , Sandra Murphy , "opsec-chairs@ietf.org" , Sandra Murphy , "opsec@ietf.org" Thread-Topic: Roman Danyliw's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT) Thread-Index: AQHVV4tUG5479ht3N0emC1fYKNZ4IacGPKht Date: Wed, 21 Aug 2019 23:21:23 +0000 Message-ID: References: <156632839487.394.4368131465284019480.idtracker@ietfa.amsl.com> In-Reply-To: <156632839487.394.4368131465284019480.idtracker@ietfa.amsl.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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.220.124] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0527b3ba-8dba-4e66-8780-08d7268e4814 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DM6PR09MB4413; x-ms-traffictypediagnostic: DM6PR09MB4413: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1388; x-forefront-prvs: 0136C1DDA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(136003)(39850400004)(366004)(396003)(199004)(189003)(14454004)(6116002)(8676002)(229853002)(4744005)(186003)(256004)(14444005)(476003)(55016002)(99286004)(3846002)(9686003)(33656002)(478600001)(53936002)(102836004)(6246003)(11346002)(446003)(305945005)(76176011)(6506007)(91956017)(25786009)(4326008)(66946007)(81156014)(66556008)(74316002)(81166006)(26005)(7696005)(76116006)(66476007)(64756008)(66446008)(7736002)(6436002)(8936002)(5660300002)(52536014)(486006)(66066001)(316002)(71200400001)(86362001)(110136005)(54906003)(71190400001)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR09MB4413; H:DM6PR09MB3019.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: I2Qr7x9Lu04SAFOmviCUEOhfxuWif4QLvqbqQHXzGFl+qhpw8MMKO9N+hZ/fmIoSpiqiRJ1ZVacbzBfs9VdgDS9ZfMsdARCj96K484OzEuTrG/weQjBlP41jV36/+Y4HpqCXkDmyzF59LdrMQKk9hvfmfUHQl/4RxHzXqxEPXuxkA2VAPsfrtvLoJgxeL2GLNF8IpRtf5S0/DW1dP+auJpIu6kOW3BN6/vMngbralU5Kqfr7zrdxDyfMI9nFxxERyIIMEppfZ7WaO3eXPBUWK3X0V+IpKS8XZ0GR/0ua3g4EunQDT9GdMnPRhakqaaHlwngyHCxzKyombHEMiGMK3G/oJXRtyyGPQZ/vZPsafxnLeOHGS5SIddjqbTUJoDTdtrTJi3QCz4rfeuhau0e4V709RBp7EUyqQfYs8ARPcn4= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 0527b3ba-8dba-4e66-8780-08d7268e4814 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2019 23:21:23.1801 (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: 1dzgHAVhjKFWEpYejwyBriTFYMlYJx2+Ba1cevjEpI6Lq94hET5gMU8dmTCOxIyBQqfawwnr68wupiZXAtF2jQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR09MB4413 Archived-At: Subject: Re: [OPSEC] Roman Danyliw's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 23:21:27 -0000 Hi Roman, Thank you for your comments. My responses marked with "[KS:]" below. ________________________________________ From: Roman Danyliw via Datatracker Sent: Tuesday, August 20, 2019 3:13 PM ... ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) I support Alvaro Retana=92s DISCUSS point about the needed clarity on algorithm selection (A vs. B) and the security assumptions being made about Algorithm A. [KS:] Yes. I am updating the draft per Alvaro's recommendations/suggestions= . (2) Editorial -- Document header: s/Updates: RFC3704/Updates: 3704/ [KS:] Yes. Done. -- Section 2.1. Editorial. s/are maintained which list/are maintained to = list/ [KS:] Done. Sriram From nobody Wed Aug 21 16:40:39 2019 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1813120043; Wed, 21 Aug 2019 16:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 4sIRdUUd5bBb; Wed, 21 Aug 2019 16:40:36 -0700 (PDT) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2107.outbound.protection.outlook.com [40.107.91.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA7EC120024; Wed, 21 Aug 2019 16:40:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WqFWVphFHSCyf6gSSTUpMuoI1AoeapymhsKXhBLVSkWreTRufeKQgokvy0yw/sOBOC+Hi3EOHoWlfZ8PULhDNzDUEY2fr0rzDmtY0e1JpGChvk4tbOTU5SgJmN23FHFVbfqqMqC8ZowIl/tqohmst31jShLHttG8loX9D30sp0n7bBESOjjbzz0MraYJVtIDjAN7j31HhXM0JIraaWZHPToq+z0kujfJuWaeELf5Vxr+HGaUC2fV6vU2bYxrWRWDvujkbk0MIpxDtdn1vq7/X8vmb3bR2pBuCYe89iXEKaxxrL5kylR2vKiINqvAqwJ+Ze7652T22NGSfyDtIzy3MA== 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=nl2LwX/vi4Qj01lLlMEad8GGNxdZxAaSfcyjRDwO8rc=; b=iINjh8ksWA+l42ZDi1nGSjPIR5aULEfoCqyP/grpOH8GFCX7DvuRhEi5ocbLrmmyJDVBcmRgw1ZKfIgksFB5iDMEVP+HKtTac30cSj6BsjdqrohUgr982/GDTVDGJ+UvhJTn0n5VT42hbf8mhjbFlkPeOj/68a1dHhPXul3wYtuSdtIaz0ozrJx9TEDTqQQX48cxdQU6uKLMwQ7YCdtUxyCLxmjgjzQflflD9ozb5Fpe4+MwokCqVCfxzzWFOY6m07j/Bx8Ck8LU74PERKiECW7h8aRc1C1wFcP6IawvtgRhy9BmzW1ZxsvKYbL1nJfFQcQjGbBggmSFKtnPa+AFtg== 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=nl2LwX/vi4Qj01lLlMEad8GGNxdZxAaSfcyjRDwO8rc=; b=e5fatTFPMW1R4BMKZBIExX4WXN0VRkpx4M4Bp2bu6anpKcKwluqL791dgckLSMsOMreIcJjIQYcpvnq2kLI6Ds2eCwha7c0nbuvFd9AmS6Z0oFhwHeiwforK5MJaSrwodTYhmwW9nVesX1Y9FR9JdwWhmexEjMU6YP7GUmofWlk= Received: from DM6PR09MB3019.namprd09.prod.outlook.com (20.178.2.203) by DM6PR09MB3033.namprd09.prod.outlook.com (20.178.2.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.16; Wed, 21 Aug 2019 23:40:34 +0000 Received: from DM6PR09MB3019.namprd09.prod.outlook.com ([fe80::fc5a:9648:8e8f:7968]) by DM6PR09MB3019.namprd09.prod.outlook.com ([fe80::fc5a:9648:8e8f:7968%6]) with mapi id 15.20.2178.018; Wed, 21 Aug 2019 23:40:34 +0000 From: "Sriram, Kotikalapudi (Fed)" To: The IESG , Martin Vigoureux CC: "draft-ietf-opsec-urpf-improvements@ietf.org" , Sandra Murphy , "opsec-chairs@ietf.org" , Sandra Murphy , "opsec@ietf.org" Thread-Topic: Martin Vigoureux's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT) Thread-Index: AQHVWAkIpkNS4V1DFUyPU5OC8U8QIacGPxOX Date: Wed, 21 Aug 2019 23:40:33 +0000 Message-ID: References: <156638238422.25801.5282209588346224957.idtracker@ietfa.amsl.com> In-Reply-To: <156638238422.25801.5282209588346224957.idtracker@ietfa.amsl.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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.220.124] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: feef63a4-f4ec-4ca5-80ec-08d72690f60a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DM6PR09MB3033; x-ms-traffictypediagnostic: DM6PR09MB3033: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 0136C1DDA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(396003)(136003)(39850400004)(189003)(199004)(446003)(81166006)(76176011)(66066001)(99286004)(7696005)(316002)(110136005)(54906003)(14454004)(6506007)(3846002)(6116002)(2906002)(478600001)(102836004)(305945005)(55016002)(9686003)(74316002)(6436002)(53936002)(71190400001)(91956017)(52536014)(76116006)(66476007)(66556008)(64756008)(66446008)(66946007)(14444005)(86362001)(33656002)(256004)(8936002)(7736002)(5660300002)(71200400001)(6246003)(476003)(8676002)(81156014)(4326008)(486006)(229853002)(26005)(66574012)(186003)(25786009)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR09MB3033; H:DM6PR09MB3019.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: uR8EyDyPNahJ9bK1GJwL8/eA9gF94JPhWcvIJVvO5cP8BBcoEhL7XYbE31+UaGrxEofNsSDd2cM9ftG+474hW74r+kukogiBhzxTI0rkjeQ143mE6iWy628p5uZfNSJoSQgJ5CdFnCA27Gyje1EEpXTBKqplr7AWSO6ipDOm6t1xnAL7aYSk+cc/lpsRz067yhiCuizeWjU3He4FmzgrbYwSCD93JU9U32EduWxGrING6g2IXi96HagajWQnN2HaXWu2ATFrF2qMqoNPpd+XeA2GfQGhuLSpd3pIjdQ+XWd4PvfWiQqUWUZyuQnFmsmgYHq3ct4LBIHz/hTy31ypeYqCBRTOcIYTN+47qLtX2nRKY7aLCxpekxtaa0Oms20ZKeu4MW2+YRwrOqTJmyXgwYL3Twho3hpiv5qHA3Ln5qc= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: feef63a4-f4ec-4ca5-80ec-08d72690f60a X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2019 23:40:34.0054 (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: LAroPf9iVgsGNRwyPv+imygwaltKy+cBCGZgOdwDovdFb+WfAp/lZz0dzsSGvRYHom7hH28ACQnwAwynJ/Ro5A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR09MB3033 Archived-At: Subject: Re: [OPSEC] Martin Vigoureux's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 23:40:38 -0000 Martin, Thank you for your comments. My responses marked with "[KS:]" below. ________________________________________ From: Martin Vigoureux via Datatracker Sent: Wednesday, August 21, 2019 6:13 AM ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Ingress/egress Access Control Lists (ACLs) are maintained which list acceptable (or alternatively, unacceptable) prefixes for the source addresses in the incoming/outgoing Internet Protocol (IP) packets. the beginning of that sentence is a bit hard to parse, but maybe it's just = for me. [KS:] The sentence now reads: Ingress/egress Access Control Lists (ACLs) are maintained to list acceptabl= e=20 (or alternatively, unacceptable) prefixes for the source addresses=20 in the incoming/outgoing Internet Protocol (IP) packets.=20 This was based on Roman's suggestion (s/which/to/). Any packet with a source address that does not match the filter is dropped. well, that really depend on the match criteria. If the list is of unaccepta= ble addresses and you don't match on these, then you should forward the packet. [KS:] The sentence now reads: Any packet with a source address that fails the filtering criterion is drop= ped.=20 Adj-RIB-Ins did you mean Adj-RIBs-In? [KS:] Yes, corrected. Figures 1 and 2 claim that EFP-uRPF works best but it has still not been described at that stage so it is a bit difficult to understand that claim. [KS:] We do refer back to those figures later again after EFP-uRPF is described. It seemed that was better than repeat the figures twice just to later add 'EFP-uRPF works best' in the second incarnation! We hope the reader will understand. Sriram =20 =20 From nobody Wed Aug 21 20:21:25 2019 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F89012003F; Wed, 21 Aug 2019 20:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_HELO_NONE=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=cert.org 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 Yrqz4UwppFqj; Wed, 21 Aug 2019 20:21:22 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 A7A3812006A; Wed, 21 Aug 2019 20:21:22 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x7M3LLB4003525; Wed, 21 Aug 2019 23:21:21 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x7M3LLB4003525 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1566444081; bh=+i2XUkfnbzAismpC5CZJG5+yjjgOLNiTi73QY1h1Er4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=gRuAsRj6Clx64pvm6xVOBZAxj4ku3Knsa5rq4g50WiOJ8UVDfgAjjvCfCXrMw5QiX 90hpq0XNJEnaNBC1+/tMQWopukVOZ7aSdNODUCRTtvuLC4McGUic8sWnpuvaUCVL5U PEMBskI4MwJSHjSWbQChb0e6OKq4ZF3UeXt5m1cU= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x7M3LJ5k010162; Wed, 21 Aug 2019 23:21:19 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0468.000; Wed, 21 Aug 2019 23:21:19 -0400 From: Roman Danyliw To: "Sriram, Kotikalapudi (Fed)" , The IESG CC: "draft-ietf-opsec-urpf-improvements@ietf.org" , Sandra Murphy , "opsec-chairs@ietf.org" , "Sandra Murphy" , "opsec@ietf.org" Thread-Topic: Roman Danyliw's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT) Thread-Index: AQHVV4tVVcueKpHF2EiLN/NtHRFUQKcGgkKA////xDA= Date: Thu, 22 Aug 2019 03:21:17 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B3439C2C@marathon> References: <156632839487.394.4368131465284019480.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OPSEC] Roman Danyliw's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 03:21:24 -0000 Hi Sriram! > -----Original Message----- > From: Sriram, Kotikalapudi (Fed) [mailto:kotikalapudi.sriram@nist.gov] > Sent: Wednesday, August 21, 2019 7:21 PM > To: The IESG ; Roman Danyliw > Cc: draft-ietf-opsec-urpf-improvements@ietf.org; Sandra Murphy > ; opsec-chairs@ietf.org; Sandra Murphy > ; opsec@ietf.org > Subject: Re: Roman Danyliw's No Objection on draft-ietf-opsec-urpf- > improvements-03: (with COMMENT) >=20 > Hi Roman, >=20 > Thank you for your comments. > My responses marked with "[KS:]" below. >=20 > ________________________________________ > From: Roman Danyliw via Datatracker > Sent: Tuesday, August 20, 2019 3:13 PM > ... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > (1) I support Alvaro Retana's DISCUSS point about the needed clarity on > algorithm selection (A vs. B) and the security assumptions being made abo= ut > Algorithm A. >=20 > [KS:] Yes. I am updating the draft per Alvaro's > recommendations/suggestions. >=20 > (2) Editorial >=20 > -- Document header: s/Updates: RFC3704/Updates: 3704/ >=20 > [KS:] Yes. Done. >=20 > -- Section 2.1. Editorial. s/are maintained which list/are maintained t= o list/ >=20 > [KS:] Done. Thanks for these updates. =20 Roman From nobody Fri Aug 30 09:07:03 2019 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF12512001E; Fri, 30 Aug 2019 09:06:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: opsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: opsec@ietf.org Message-ID: <156718121282.25743.666171508280455839@ietfa.amsl.com> Date: Fri, 30 Aug 2019 09:06:52 -0700 Archived-At: Subject: [OPSEC] I-D Action: draft-ietf-opsec-urpf-improvements-04.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 16:06:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure WG of the IETF. Title : Enhanced Feasible-Path Unicast Reverse Path Forwarding Authors : Kotikalapudi Sriram Doug Montgomery Jeffrey Haas Filename : draft-ietf-opsec-urpf-improvements-04.txt Pages : 20 Date : 2019-08-30 Abstract: This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38). The strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704). However, as shown in this document, the existing feasible-path uRPF still has shortcomings. This document describes enhanced feasible- path uRPF (EFP-uRPF) techniques, which are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC 3704). The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV). Hence they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers, and encourage greater deployment of uRPF techniques. This document updates RFC 3704. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-urpf-improvements/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsec-urpf-improvements-04 https://datatracker.ietf.org/doc/html/draft-ietf-opsec-urpf-improvements-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-urpf-improvements-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 30 10:43:56 2019 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F391200B8; Fri, 30 Aug 2019 10:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Q_8naQVgg1Xa; Fri, 30 Aug 2019 10:43:51 -0700 (PDT) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2130.outbound.protection.outlook.com [40.107.91.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA8812080D; Fri, 30 Aug 2019 10:43:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hZnXN0hw52RJyDIDFfoAexQnh/W0qmemyFaqQjOrkwKMX0EZyZolOBA5gWdqjUtio+QlMLhxXRZYcSlaYWUANz68Vof8WZALXNSrJDHY8RRl8OasWNuDRcPTZaWP+i18OCKUCsPiDFOy3lXgEuKNw/iBNdpxOgwpuGkJ1C3EwfuLMEY7ZAOx3qz1jel+c9TRI4+VftZXM/FzlQ85lPkKWo+AhIhTW1jLVAX2ZVO7Y+T1hpeyfO7f3Es5QA/272zYktriU+NHxFRnjAWTB1E00Gol8//qPpdz7OVQ94dL0guWIC/vF54l87Br6EF/4adhbnleGMLR+otk5mFlAL3wJA== 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=Ga1MiVVLly87Uo6B+hRfu2UzCTisgMdNXjn3PykD6FM=; b=SjCFlJduscb+fA+nADt70CfjabyJgmFvbxPrQRRvjEhreG3YCioy9pJUtExdOpf0u2m3isr95cfppEYJLr7uP8w71ERcWAi3uNfEfafmr639jkxraEKCyKzQHxgQor0BkAQRnMFF/5dxsQk9VvFIW6Pcgzzmc9L1THdtWa1efeuc/0xdHuGe5XRHEF0GwC3cdlGKuBmxfGl5UA342OmFuY+b3lQGMMzi3BVyFqB5v6VvZkn85qo5uU5onnEwibyzzP2ugPWukVtzRBmRoHuPIkMAJO+VkrAljb+7ejAjTk3OGpumZtiuKNhKnN1IfYKj4Un1j8YDbMXvPyTKNSkuEw== 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=Ga1MiVVLly87Uo6B+hRfu2UzCTisgMdNXjn3PykD6FM=; b=Dgpaot/T6ZRWSR4QxNp4Kwegp/j47ve6+7QgRTsa3W1p4vDnkOp8VlheYDiyDZOwH2Qo6ZFRjxWA2CG9g99qxnbCsahW9LEHn03C43Kl5hX76IqkopNku5unaUd0NU475MZF8MUOniXiFtss33Js4zKj8TqHRVtsekBJt4K/MsM= Received: from BL0PR0901MB4563.namprd09.prod.outlook.com (52.135.47.206) by BL0PR0901MB4308.namprd09.prod.outlook.com (52.135.47.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.19; Fri, 30 Aug 2019 17:28:20 +0000 Received: from BL0PR0901MB4563.namprd09.prod.outlook.com ([fe80::b532:35b9:abd0:ee7e]) by BL0PR0901MB4563.namprd09.prod.outlook.com ([fe80::b532:35b9:abd0:ee7e%4]) with mapi id 15.20.2220.013; Fri, 30 Aug 2019 17:28:19 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Alvaro Retana , The IESG CC: "Murphy, Sandra" , Sandra Murphy , "draft-ietf-opsec-urpf-improvements@ietf.org" , Jen Linkova , "opsec@ietf.org" , "opsec-chairs@ietf.org" , Warren Kumari Thread-Topic: Alvaro Retana's Discuss on draft-ietf-opsec-urpf-improvements-03: (with DISCUSS and COMMENT) Thread-Index: AQHVVH41+WK2q56zSkaIVPY4TX30Q6cBbRMZgAGRGwCAARoHb4AAGHgAgAAaK2mAD7LyAg== Date: Fri, 30 Aug 2019 17:28:19 +0000 Message-ID: References: <156599290421.23877.9763694862590191063.idtracker@ietfa.amsl.com> , , In-Reply-To: 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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.223.123] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dba5d49f-08dd-471b-06d1-08d72d6f7394 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BL0PR0901MB4308; x-ms-traffictypediagnostic: BL0PR0901MB4308:|BL0PR0901MB4308: x-ms-exchange-purlcount: 1 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0145758B1D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39850400004)(376002)(136003)(366004)(346002)(189003)(199004)(66066001)(52536014)(54906003)(110136005)(6436002)(5660300002)(256004)(102836004)(6506007)(4326008)(71200400001)(486006)(11346002)(25786009)(71190400001)(316002)(476003)(6246003)(229853002)(66946007)(186003)(33656002)(26005)(99286004)(66446008)(64756008)(66556008)(66476007)(76116006)(9686003)(81156014)(55016002)(53936002)(446003)(14444005)(3846002)(76176011)(6116002)(14454004)(86362001)(966005)(478600001)(2906002)(7696005)(6306002)(7736002)(305945005)(8936002)(8676002)(81166006)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR0901MB4308; H:BL0PR0901MB4563.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: y+AzwCE1+oUhneNOKdhw/TjOl1Lp4XMAj5/1mXIhzGT37C/VjpJmSKygbTRP97VRiDgxNkMmqEeU3aQiJ2Bda+AJVwnQ7qS7z3xNUzATF4qWqPppJ+0m9ctzsgYhno/+13E5Ci3ktpsZAhwfQTjVYP3FsA5GR3yqjsjkVJ5fo465Gd7fJWKmLMR88t4g8E08H01yRa/qIqUwPCfFQZkQeqgozrJQNMLYdRTk9CxEFyjRoxH4pY5KT07lDUOBGiKJ8wXtrMIwI2IPpgcRzgFUvi5XztqNqx8jvyIVZE7AUHj0QftLfW1VPRS0cFQeNidz5ouHE70JQeHTWnr4GbAtULYwSYmWCjqH7aAfLR5krgiVa2rxnYGa8eumsWBuFsDmpLh3KZiRIssq11zqIB9m09zopk4zG6X1LeoM0qBI5Y4= Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: dba5d49f-08dd-471b-06d1-08d72d6f7394 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2019 17:28:19.8043 (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: 58MJqOill7FkzjR3D62OTK/TfQd9O5/yFl+A+pWbwmp110ruEdpTH1FnjCqv2rKL2qSencdBPim0mjO1zJF+8A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR0901MB4308 Archived-At: Subject: Re: [OPSEC] Alvaro Retana's Discuss on draft-ietf-opsec-urpf-improvements-03: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 17:43:55 -0000 Alvaro, A new version -04 has been uploaded that includes changes based on your Discuss and other comments. It took sometime because we (authors) thought it was best to=20 incorporate all of the IESG reviewers' comments before uploading a new version. That is done now.=20 >.... >Given that Algorithm B is more flexible, and that the limitations from Alg= orithm A are overcome (=A73.4), I would like to see B be the recommendation= . >... >I am ok if Algorithm A is mentioned as an alternative (not a recommendatio= n); one that is less flexible and has specific limitations =97 even if thos= e limitations are not expected/assumed, the vulnerability to a change in co= nditions should be clearly spelled out. >... These main changes per your recommendation are incorporated. Please take a look at the revised Section 3.7, where we've added=20 a new Section 3.7.1 to speak about applicability and limitations of Algorit= hm A. You may take a look at the diff: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-urpf-improvements-04= .txt >Yes=85but it is important to clearly mention the known vulnerabilities of = the solutions being proposed. We have carefully revised the Security Considerations section. There we mention again the limitations of Algorithm A=20 and refer back to Section 3.7.1 for details. We also discuss (in the Security Considerations) the risks of augmenting the RPF list based on ROA data (per your suggestion).=20 We also mention the need for "security hardening of =20 routers and other supporting systems (e.g., Resource PKI (RPKI) and=20 ROA management systems) against compromise..." Please let us know if you have any additional comments. Thanks very much for your help. Sriram= From nobody Fri Aug 30 12:41:37 2019 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3C21209EB; Fri, 30 Aug 2019 12:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 cIeSiqfRLOYk; Fri, 30 Aug 2019 12:41:32 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FEFB1209C9; Fri, 30 Aug 2019 12:41:32 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id r12so9234891edo.5; Fri, 30 Aug 2019 12:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=wamo5NCScZ6Dqt+qjUJ3UP1WolaYx7oxBy9eOX820VY=; b=K3YmG513cJ1/vIFUZgfYThfwgYtmmftqB7qv4kyRyjh0Gp0RTsPnnfa5BBIirw/G6j aEGO7rlG+xPqkrJRBibGZtecS1LE992m7QafsQ4oZ7Rqk7ETSATEDNN1mkE4rAnQUd8Y fejfgb5lYh+wSjiWaxwMF/eOAn6k5ZzgjseumuMJda61rvSaKmtejg/fFi5kk3CtONPG EWPLrn+JphEHZ1bMHtK3Z5O8Itn1PJPG8tvy/aO0moi4cxtFYmZfFgnRwxl982v97A8R cNtHhNLe+IDdxrGvbCE3vE+wS3ZvRUuYH054lifon2CWqlLEXvIQNOQ0anNzVbeUa35S 320w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=wamo5NCScZ6Dqt+qjUJ3UP1WolaYx7oxBy9eOX820VY=; b=K2QlIrUOYxKPmefzUX3sZzAoMrwnx0BETVmy59SduGewiyptN4Cq5UrNLydGtdbPC1 hao63sEDKUaAWsEnw3jSDCzq6TBQq69ib/RW275/IXHVoMPzFzYZhDRqL+MxsVJaf9YZ 4fOvOWg1SL7M9R6sJ2ExKlMp5fAlZwqf58XEJ5YEjejkUpIZSabcT8TBuIxHn3VTkooK OJVM31ZSsX+VHlm7rR3gf7VODkCvdcLW2a0BWbdkaynW/GOqYWJ16y/b853t9GTq1Jac 91jMYU6mm/kCGRAlHbbnVpYDF3ABCpCqGGLyaU/l8/okXWCkv3FLBBJycFtwjswWIeHk +FUQ== X-Gm-Message-State: APjAAAWsEARcy9XPdmK5MRNB28Dz32JEc/ZKQ5Huf3kucf1GIw1P8Dkw aYvn8vxxz7DGE0v972ZvoPXGYwuOe6QZhcbMPo4= X-Google-Smtp-Source: APXvYqyVndGbcMDflUX8Xlz2aJFq6QQxmyeqv/mups0mDS//ROUhvEsrKyVdwztKEIS3P1tHx/0EPKbhBKxH/OMcxRU= X-Received: by 2002:aa7:c655:: with SMTP id z21mr17467139edr.87.1567194090589; Fri, 30 Aug 2019 12:41:30 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 30 Aug 2019 15:41:29 -0400 From: Alvaro Retana In-Reply-To: References: <156599290421.23877.9763694862590191063.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Date: Fri, 30 Aug 2019 15:41:29 -0400 Message-ID: To: "Sriram, Kotikalapudi (Fed)" , The IESG Cc: Warren Kumari , Sandra Murphy , "opsec-chairs@ietf.org" , "Murphy, Sandra" , Jen Linkova , "draft-ietf-opsec-urpf-improvements@ietf.org" , "opsec@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001051a305915acf01" Archived-At: Subject: Re: [OPSEC] Alvaro Retana's Discuss on draft-ietf-opsec-urpf-improvements-03: (with DISCUSS and COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 19:41:35 -0000 --0000000000001051a305915acf01 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Sriram! I=E2=80=99m clearing my DISCUSS. Alvaro. On August 30, 2019 at 1:28:22 PM, Sriram, Kotikalapudi (Fed) ( kotikalapudi.sriram@nist.gov) wrote: Alvaro, A new version -04 has been uploaded that includes changes based on your Discuss and other comments. It took sometime because we (authors) thought it was best to incorporate all of the IESG reviewers' comments before uploading a new version. That is done now. >.... >Given that Algorithm B is more flexible, and that the limitations from Algorithm A are overcome (=C2=A73.4), I would like to see B be the recommendation. >... >I am ok if Algorithm A is mentioned as an alternative (not a recommendation); one that is less flexible and has specific limitations =E2= =80=94 even if those limitations are not expected/assumed, the vulnerability to a change in conditions should be clearly spelled out. >... These main changes per your recommendation are incorporated. Please take a look at the revised Section 3.7, where we've added a new Section 3.7.1 to speak about applicability and limitations of Algorithm A. You may take a look at the diff: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-urpf-improvements-04= .txt >Yes=E2=80=A6but it is important to clearly mention the known vulnerabiliti= es of the solutions being proposed. We have carefully revised the Security Considerations section. There we mention again the limitations of Algorithm A and refer back to Section 3.7.1 for details. We also discuss (in the Security Considerations) the risks of augmenting the RPF list based on ROA data (per your suggestion). We also mention the need for "security hardening of routers and other supporting systems (e.g., Resource PKI (RPKI) and ROA management systems) against compromise..." Please let us know if you have any additional comments. Thanks very much for your help. Sriram --0000000000001051a305915acf01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Thanks Sriram!

I=E2=80=99m clearing my DISCUSS.

Alvaro.

On August 30, 2019 at 1:28:22 PM, Sriram, Kotikalapudi (Fed) (kotikalapudi.sriram@nist.gov) = wrote:

Alvaro,

A new version -04 has been uploaded that includes changes
based on your Discuss and other comments.
It took sometime because we (authors) thought it was best to =20
incorporate all of the IESG reviewers' comments before uploading
a new version. That is done now. =20

>....
>Given that Algorithm B is more flexible, and that the limitations f= rom Algorithm A are overcome (=C2=A73.4), I would like to see B be the reco= mmendation.
>...
>I am ok if Algorithm A is mentioned as an alternative (not a recomm= endation); one that is less flexible and has specific limitations =E2=80=94= even if those limitations are not expected/assumed, the vulnerability to a= change in conditions should be clearly spelled out.
>...

These main changes per your recommendation are incorporated.
Please take a look at the revised Section 3.7, where we've added = =20
a new Section 3.7.1 to speak about applicability and limitations of Alg= orithm A.
You may take a look at the diff:
https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec= -urpf-improvements-04.txt

>Yes=E2=80=A6but it is important to clearly mention the known vulner= abilities of the solutions being proposed.

We have carefully revised the Security Considerations section.
There we mention again the limitations of Algorithm A =20
and refer back to Section 3.7.1 for details.
We also discuss (in the Security Considerations) the risks
of augmenting the RPF list based on ROA data (per your suggestion). =20
We also mention the need for "security hardening of =20
routers and other supporting systems (e.g., Resource PKI (RPKI) and =20
ROA management systems) against compromise..."

Please let us know if you have any additional comments.
Thanks very much for your help.

Sriram
<= /div> --0000000000001051a305915acf01-- From nobody Fri Aug 30 17:23:34 2019 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8D9120089; Fri, 30 Aug 2019 17:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Jh8XjMZ_RLHh; Fri, 30 Aug 2019 17:23:27 -0700 (PDT) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2127.outbound.protection.outlook.com [40.107.91.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989C4120077; Fri, 30 Aug 2019 17:23:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XkjBbYuhzPFocUOkA15376b56f19Y99F3nBsE8SNFcTsnPBZBHKpN18MxmOHLTC/zbOzbE8I6y1xvYg8vu18aXC+X2CZcl2Wd4i8Dnpmnn5VdckB78TsjHW/0TdJsZT8NuWpk+HKU6OlZK/VCsrehzvth7Bx6+B8LClV8rGUWHVZN+BLzClrve4zcb3op7PBdM09Uuyh9f/4OpYAWWWef30NgvwzkR/jhZymwaIofXpakiqVGiHYkBzjBnD4t4is45vkDJhRE6f34pwmTHGyLMA6JnfLba9WGsyjlbDIJcN1SZw1zo7ul5ret45eO4yij9qDpYzfsSMh1yKIHZdq/g== 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=FI6HrNm/WuZyPvXudasy2L6asQnomm4BCeGF+OZKj8c=; b=OFqjfcar2X96UuHxVd57vZeWs8Qm7xuY6xi6aCglXNlqPF8Oyud9rQlHHLSA1fpT9mE5DcgOe5J0Pc3fdhZDWYlAsh3C9IPKvDFFvlZ9IzCa4gGLJGyjCfnB1trKG+xtSFjuX2oVPrXHRsWzZHmqJAWfNbkLyJqN5aXRmNtyIlaWqnXjD3NqTY9uRCAtItk38zA4IIRUrSxAmnUnb72odobHPvcc8MUkP7mMddq3Qmx2wcAhbHIMKcjp7UGnVW1syXXBNROSw4SH1WuHUxVsgwN1UExVCIi6Dh6QnkwdCUT/jIs9PFSrj6gbMYiXvyE9whZAJgVg2duss0GeGCoWzQ== 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=FI6HrNm/WuZyPvXudasy2L6asQnomm4BCeGF+OZKj8c=; b=BhI6IeR6yNgA3BbGULzZG/Inc3YtYduck6DALYM2K19GTT0gJbwYrZc10GHI498VQG1zlg0dLs9WCRwtndGeRLpR5CNJebXJk8ynXG4YtZowCrk6Zv4mZbJeZUX5il/vY3jfiwV3tkPJAbhEH6D1XDhxrf5T8Qyce8klm/I6kQE= Received: from BL0PR0901MB4563.namprd09.prod.outlook.com (52.135.47.206) by BL0PR0901MB3089.namprd09.prod.outlook.com (20.177.243.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.20; Sat, 31 Aug 2019 00:23:25 +0000 Received: from BL0PR0901MB4563.namprd09.prod.outlook.com ([fe80::b532:35b9:abd0:ee7e]) by BL0PR0901MB4563.namprd09.prod.outlook.com ([fe80::b532:35b9:abd0:ee7e%4]) with mapi id 15.20.2220.013; Sat, 31 Aug 2019 00:23:25 +0000 From: "Sriram, Kotikalapudi (Fed)" To: The IESG , Benjamin Kaduk CC: "draft-ietf-opsec-urpf-improvements@ietf.org" , Sandra Murphy , "opsec-chairs@ietf.org" , Sandra Murphy , "opsec@ietf.org" Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT) Thread-Index: AQHVWHIsB4ZVbuMqYUKEVO70JjT76qcUZ2WK Date: Sat, 31 Aug 2019 00:23:24 +0000 Message-ID: References: <156642754067.25756.14564875013672898583.idtracker@ietfa.amsl.com> In-Reply-To: <156642754067.25756.14564875013672898583.idtracker@ietfa.amsl.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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.223.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f680726a-d46c-408d-b9f2-08d72da97035 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BL0PR0901MB3089; x-ms-traffictypediagnostic: BL0PR0901MB3089: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 014617085B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39850400004)(136003)(376002)(346002)(366004)(189003)(199004)(53936002)(76116006)(14454004)(2906002)(6116002)(478600001)(3846002)(71200400001)(81156014)(66066001)(86362001)(966005)(81166006)(4326008)(110136005)(66476007)(66446008)(64756008)(6506007)(8676002)(8936002)(71190400001)(9686003)(55016002)(186003)(6306002)(229853002)(66556008)(5660300002)(99286004)(316002)(486006)(6246003)(102836004)(76176011)(26005)(25786009)(33656002)(7696005)(7736002)(446003)(52536014)(305945005)(66574012)(11346002)(14444005)(54906003)(6436002)(476003)(2171002)(256004)(74316002)(66946007); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR0901MB3089; H:BL0PR0901MB4563.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ySgsfjLT+KHCVEn3fxgF33TuG25puSKezTTDTo73uTJ8wdSUSyJwuVnv6ZQU5MwiifjIYobRXVdyX73RKjs0tUWZ4DuC9t0Aedwgrl6gKUj4kXGwT3ahdjZEYpfbR/wImApSjkgY8SwPuH8Ih3byrISqSLSpC8ewgx1Jz+rjeqV677kG0GBeR8N3wzQLevNiVez9rHQ/vtEJ6HjS49KMLAYVGQ5K40bCiTgC05Q3Yw1cIQmYgF73JnjSJ8Bzf155atPQPH/MOTmQc2qwRIvlBcSSYIpXNHQmZi+6P+Fsf0O8wG51ZIvrfBuFbFIWWg0hOqPgDLAV+C8wPWWjhnUcndKNQIuWxsgX2I7+NgND3Y6oIcj4/LhXJnxa3gMxiVt8DsLnnzQiwzPGxC2bFEwyN2PabC2N+vDT/TytxTqvvGo= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: f680726a-d46c-408d-b9f2-08d72da97035 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2019 00:23:24.9575 (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: ZbF0eptIuaZmokV8uZGpjgrvJlL6yz36I01CvwVfpV8RjybAEix7eOFeDptA7ipG/WjXGyND5/KyfCUJNuOzeQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR0901MB3089 Archived-At: Subject: Re: [OPSEC] Benjamin Kaduk's No Objection on draft-ietf-opsec-urpf-improvements-03: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 00:23:31 -0000 Hi Benjamin, Thank you for your comments. Sorry about the delay in replying. We have uploaded a new version and have included changes reflecting your comments. Please see: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-urpf-improvements-04= .txt =20 Please also see responses to your comments inline below.=20 >Thank you for this well-written document! It will be beneficial to the >security of the internet as a whole to have effective BCP38 protections >applied more widely. > >I'm happy to see the discussion about Algorithm A vs. B as recommended >default, prompted by Alvaro's ballot position. On the face of things I >do share his concern, as having "safe defaults" in the sense of not >dropping legitimate traffic seems pretty compelling, but I do recognize >that Algorithm A produces a stricter check, and that is in a different >sense "more safe". I don't think I have much to add to the discussion, >though, so I'll continue to watch it play out. (Perhaps some of the >discussion could make it into the security considerations of this >document once things get settled, though.) > Yes, what you are saying is true as well =85 =93Algorithm A produces a stri= cter check,=20 and that is in a different sense "more safe".=94 =20 Please see if Section 3.7.1 is sufficient for now from your perspective. For an AS operator who is confident of their scenario,=20 or willing to make a possible trade-off, I think the document=20 is not stopping them from using Algorithm A. =20 =20 >Section 2.1 > > dropped. The ACLs for the ingress/egress filters need to be > maintained to keep them up to date. Updating the ACLs is an operator > driven manual process, and hence operationally difficult or > infeasible. > >nit: hyphenate "operator-driven" > Done. >Section 2.2 > >In Figure 1, I'm having a hard time understanding why feasible-path uRPF >fails for case (2). Or is the intent of the caption and terminology >note from above only to say that it fails for at least one of the >enumerated cases? (On the other hand, there's a decent chance that the >lack of comprehension is entirely on my end...) > Actually, both enumerated cases fail at AS2. Feasible-path uRPF is applied per interface; it does not matter what other prefixes were received on other interfaces (the same origin AS or not). AS2 rejects IP packet with SA in P2 on the interface with AS1. Further, AS2 also rejects SA in P1 on on the interface with AS3 (for IP packets received from AS1 via AS3).=20 Note that AS2 has not heard a BGP update for prefix P1=20 on the AS2-AS3 BGP session.=20 >Section 2.3 > > can be described as follows. In Scenario 2 (described above, > illustrated in Figure 2), it is possible that the second transit > provider (ISP-b or AS3) does not propagate the prepended route for > prefix P1 to the first transit provider (ISP-a or AS2). This is > because AS3's decision policy permits giving priority to a shorter > route to prefix P1 via a lateral peer (AS2) over a longer route > learned directly from the customer (AS1). In such a scenario, AS3 > would not send any route announcement for prefix P1 to AS2 (over the > >I expect this is just my lack of familiarity here, but does the decision >policy "giving priority" to shorter routes vs customer routes mean that >it won't propagate the customer advertisement at all or just that it >won't route traffic that way? > Yes, under this policy ("giving priority" to shorter routes),=20 AS3 won=92t propagate the customer advertisement for P1 towards AS2 since it selects the =93shorter=94 route via AS2. It will route traffic with destination address in P1 towards AS2, and the traffic will reach AS1 via AS2.=20 That is how depref with AS prepends is supposed to work (except when AS2's policy is to prefer customer route). >Section 3.2 > > o Additionally, from the routes it has learned from customers, a > non-stub AS SHOULD announce at least one route per origin AS to > each of its transit provider ASes. > >What are the security consequences of this? If, say, an AS only get >very specific prefixes with very short paths from a customer and is now >"forced" to advertise at least one of them by these practices, can that >have a negative impact on routing? Would prepending itself in the path >be a usable mitigation? > If you are thinking that the path length for the more specific route=20 will be shorter, that is not the case. The AS follows the normal BGP protocol process and adds its own ASN in the path. Please let me know if I misunderstood the question. >Section 3.4 > >nit: there's perhaps room for harmonization of language between step (3) >here and step (1) of Algorithm A. I think I understand what you are thinking. I did a little harmonizing (pl= ease see the diff).=20 I feel that full harmonizing is not worth the effort. =20 > > 4. Create the set of all unique prefixes for which routes exist in > Adj-RIB-Ins of all lateral peer and transit provider interfaces > >Is the intention that "lateral peer and transiti provider interfaces" is >equivalent to "all interfaces that are not directly-connected customer >interfaces"? Yes. >Section 3.6.1 > > The techniques described in this document require that there should > be additional memory (i.e., TCAM) available to store the RPF lists in > >nit: TCAM isn't listed as "well-known" at >https://www.rfc-editor.org/materials/abbrev.expansion.txt , so we >probably have to expand it. Done. > > The following table shows the measured customer cone sizes for > various types of ISPs [sriram-ripe63]: > >The table contents make it seem like these are not "per-type" data, but >rather specific data from hopefully representative samples. In >particular... > > +---------------------------------+---------------------------------+ > | Type of ISP | Measured Customer Cone Size in | > | | # Prefixes (in turn this is an | > | | estimate for RPF list size on | > | | line card) | > +---------------------------------+---------------------------------+ > | Very Large Global ISP | 32392 | > | ------------------------------- | ------------------------------- | > | Very Large Global ISP | 29528 | > >... perhaps these should be #1 and #2 to disambiguate. > Done. >Section 3.7 > > * In general, loose uRPF method for SAV SHOULD be applied on > lateral peer and transit provider interfaces. However, for > lateral peer interfaces, in some cases an operator MAY apply > EFP-uRPF method with Algorithm A if they deem it suitable. > >Since step (1) of Algorithm A explicitly says "of customer interfaces", >we probably need a little bit more text here to say what it means to use >Algorithm A for lateral peer and/or transit provider interfaces. (Or, >perhaps, some reworking of the text describing Algorithm A, but that >seems like a more invasive change. The recommendation now read as follows in the updated draft: * Loose uRPF method SHOULD be applied on lateral peer and transit provider interfaces. The mention of Algorithm A for lateral peer is moved to Section 3.7.1 where is says: On a lateral peer interface, an ISP may choose to apply the EFP-uRPF method with Algorithm A (with appropriate modification of the algorithm). This is because stricter forms of uRPF (than the loose uRPF) may be considered applicable by some ISPs on interfaces with lateral peers. > >Section 4 > >This is rather related to Alvaro's Discuss, but how is an AS operator to >know what type of peer and the nature of customer cone scenario that >applies to a given case? The paragraph now reads: The security considerations in BCP 38 [RFC2827] and BCP 84 [RFC3704] apply for this document as well. In addition, if considering using EFP-uRPF method with Algorithm A, an ISP or AS operator should be aware of the applicability considerations and potential vulnerabilities discussed in Section 3.7.1. Section 3.7.1 is new and talks about applicability details regarding Algori= thm A. > >Also, is there a way to know what the probability of dropping legitimate >data packets is other than experimenting and waiting for customer >complaints? Such modeling is tricky. If the ISP knows that a customer prefix is missing= =20 in their RPF list, they would simply add it rather than estimate that it is= =20 x% of the overall traffic. We tried to measure the frequency of use of NO_EXPORT from Routeviews data. Only one Routeviews collector (out o= f=20 40 overall) located at Oregon showed some updates with NO_EXPORT.=20 NO_EXPORT is hard to measure because it naturally does not propagate=20 beyond the first ISP. The collector has to be peering with ASes closer to the edges of the Internet which is rare it appears. =20 > >(I guess it's probably okay, given the references, to not bother >explicitly saying "erroneously dropping legitimate packets is bad".) > Thanks again for your very helpful comments. Sriram From nobody Fri Aug 30 17:52:08 2019 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513051200B7; Fri, 30 Aug 2019 17:52:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 4VkiMpJB9zdP; Fri, 30 Aug 2019 17:52:02 -0700 (PDT) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2137.outbound.protection.outlook.com [40.107.89.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED1F81200B1; Fri, 30 Aug 2019 17:52:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DG4ORTrIoinR4W30ztc9VdpxIHoV/f8vbVuxWniYj+xnqcoageMcgkXdT39DmUYKeKAqq7F9TBcVXvr/2dBGuB1f7AsFS7ki2Zqakzm2R5knBIkks80jj9c6VC2Lbp9sY825PepsGnLYuo0WxVCgje7bxOyw5kPb72irFimWXUwxAWDb0tIMtKZDb3J9S4IulbYBiREbcJwyhyK+WXFFCo7rwYPdxRdjBCO/nqviosv3NlKzEtJldOspsGPOnRhjv2vJLg9IcoxPyV5NKhF3jPB+qCc5abt0IFkXjdwtNiIRboW+n4xC7KzvPdXOmtBSotsO2NCd9SF/gVM1h8ISUw== 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=ifDgFJFkoY7GxCSQ0Yt1iPsPg88VNS5kQqLn0siPQ00=; b=EPh84Hsf86RSFBMiIhOHZFeibxh79JOho7Nd/JUwZ5SJHT23f420tuKiXVlv0mcIabRmEzAzhjA025d8hbzMCqH6DEopnsBGNCDPwyIA0yDBWERuWFCW2jCjK4nZMitxEZfnqBMI94X9s/aOp1ENuhUoUG12XfKhNntqkmsGArQihEJzeYNEu9JSVtJBt8YN/DCaJ6VwapD2A1Yga/NVoN76fz7ELxZGAv4S0GnN1tswlAVn2cTdHiX/8G2WswLILgr8MDyElTNUcYbF01qZv87RA+ls5G4L+1b/euz2mTy1853VNfEDaCmgDS0ko2Gj5FI4v9FwmFNrCPVIpW5miw== 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=ifDgFJFkoY7GxCSQ0Yt1iPsPg88VNS5kQqLn0siPQ00=; b=fT5HswcoWRVinKxbtUDCzpmFLW9xIFZRAZ5HpfDkFgw4H8TkB5NK5FEPTxHfn+bkuUBgdknKFX7w5cLNapJ2iJG8+uFLrbMaoGMN7VbKUugf91tafiozuM/rmW+VuUcjHX2ISmlYfZumxXc6nCw7xl7UFQ/KB6IxO2NM2dG+J0s= Received: from BL0PR0901MB4563.namprd09.prod.outlook.com (52.135.47.206) by BL0PR0901MB3171.namprd09.prod.outlook.com (20.177.243.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.19; Sat, 31 Aug 2019 00:51:58 +0000 Received: from BL0PR0901MB4563.namprd09.prod.outlook.com ([fe80::b532:35b9:abd0:ee7e]) by BL0PR0901MB4563.namprd09.prod.outlook.com ([fe80::b532:35b9:abd0:ee7e%4]) with mapi id 15.20.2220.013; Sat, 31 Aug 2019 00:51:58 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "Bocci, Matthew (Nokia - GB)" , "rtg-ads@ietf.org" CC: "rtg-dir@ietf.org" , "opsec@ietf.org" , "draft-ietf-opsec-urpf-improvements@ietf.org" , "Murphy, Sandra" , Jen Linkova , "opsec-chairs@ietf.org" , Warren Kumari Thread-Topic: RtgDir review: draft-ietf-opsec-urpf-improvements03.txt Thread-Index: AQHVWCSLk+WxzCivaUqM/Uc+Pc7zTqcUdRis Date: Sat, 31 Aug 2019 00:51:58 +0000 Message-ID: References: <695D6B79-C68C-47FB-9950-CE50233E9BDC@nokia.com> In-Reply-To: <695D6B79-C68C-47FB-9950-CE50233E9BDC@nokia.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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.223.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7478b2f6-7b98-4db8-c05f-08d72dad6d6c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BL0PR0901MB3171; x-ms-traffictypediagnostic: BL0PR0901MB3171: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 014617085B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39830400003)(396003)(376002)(136003)(346002)(189003)(199004)(2501003)(486006)(54906003)(110136005)(3846002)(7696005)(8676002)(6116002)(476003)(446003)(11346002)(71190400001)(71200400001)(52536014)(66556008)(2906002)(5660300002)(86362001)(33656002)(25786009)(66446008)(66476007)(76116006)(66946007)(4326008)(478600001)(6436002)(316002)(53936002)(229853002)(6246003)(64756008)(66574012)(66066001)(55016002)(102836004)(26005)(186003)(99286004)(74316002)(7736002)(305945005)(14454004)(9686003)(256004)(6306002)(14444005)(81156014)(81166006)(76176011)(8936002)(966005)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR0901MB3171; H:BL0PR0901MB4563.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /4H0wiAZlnS93jBE2yDHqjW1xwnMs8HwT+Zo6+KeO1RPIkQhCv0KcEmc1BrZcybMAXc5S03PtPreyCVG0NgRJ83WchF5Du1eP3pwNCmpLNatMAXCYNU1aZHq5AqFGc6xJON0zzrW4FvwpJL43Nr+fC2bjIGnf0C9IoBwIRIkUKiMkzBTHq6JqrpvUxbk73OEB0vw02SJbr9oK1/qWR508rxNey2+2XZvMGsk5smxz2pm0cEuZYjtMfSB8UW225+WL6YrDubveVAouXJJh1r0Rw0W/ZXlvjYLtqEm380B8F4qBG8xZQbstLZUURnxyRLTCO31yBXU4Pdy+nj8amKzduP8mMKSqe37w6ryekA0EVzk6qVRfO1itn3qsrWAJHCSX/jb9X7vj8PU413VG7m9DM39fyLdLO1sFMLOIzb4i44= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 7478b2f6-7b98-4db8-c05f-08d72dad6d6c X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2019 00:51:58.2288 (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: 1ARx0E+HT1aObJvLej4pFjWqUJ6WuaTq2uI3RlNNIHfwqlZ3Kg7GhMIcm9WxxV+iZZ564I+ZlVPCjBg+eBGydA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR0901MB3171 Archived-At: Subject: Re: [OPSEC] RtgDir review: draft-ietf-opsec-urpf-improvements03.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 00:52:06 -0000 Matthew: Thank you for your comments. Sorry about the delay in replying. We (authors) have uploaded a new version and have included changes reflecting your comments. Please see: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-urpf-improvements-04= .txt =20 Please also see responses to your comments inline below.=20 >Summary: >I have some minor concerns about this document that I think should be reso= lved before publication. > > >Comments: > >Generally, I found the draft quite readable, with a clear explanation of t= he problem statements and solutions as well >as the trade-offs on the implementation. However, I have one minor comment= and a nit. > >Major Issues: > >No major issues found. > > >Minor Issues: > >Terminology: The document expands 'uRPF' as 'unicast reverse path filterin= g'. However, I >believe that uRPF commonly means 'unicast reverse path forwarding' (see = RFC3704 and >most vendor documentation). "Ingress filtering" is the general concept and= "reverse path > forwarding" the specific algorithm. Did the authors intend to use a new t= erm, and if so why? > Great catch. I am surprised we (authors) overlooked and no one else caught = it for so long. Thank you! Fixed.=20 > >Nits: > >Section 2.5: "...separate from the global Routing Information Base (RIB) [= Juniper][RFC4364]." >VRFs are supported by most vendors so I think it is sufficient just to ref= erence RFC4364. > The sentence now reads: The Virtual Routing and Forwarding (VRF) technology [RFC4364] [Juniper] allows a router to maintain multiple routing table instances separate from the global Routing Information Base (RIB). Shuffled the order of references. Keeping [Juniper] because there is some=20 tutorial material in it that may be helpful for some readers. Regards, Sriram =20 From nobody Fri Aug 30 21:46:29 2019 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28B512004C; Fri, 30 Aug 2019 21:46:20 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 XnXd95631pQe; Fri, 30 Aug 2019 21:46:17 -0700 (PDT) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2102.outbound.protection.outlook.com [40.107.89.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AC0E120026; Fri, 30 Aug 2019 21:46:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UP1/eCHqEz7x9tLvs+SAYGUBmUxwdU17Tr3ERqfIoaRMcfkq7kjoh765i5V/ZUrRii7snktwnIDF7xWJLkaCFYNnYnKwlf5ij3xbC/8JCKcMhf7ySzKybISYog067S8UG2BFD8q9V4njbcE79RzMxkbXIsqIF/y3jliB4uIsNUTrksgCAl8xJbeJFda5d21lsh5QdVtQ2T4ZW1LZN68hqaNJF1Z/RoTbHuhAa0rMvaXiT/v+Ze607dxupd1tKrcNHskW5GQTXdIn3JiHU6BYrlv/EwaVhGA6xafLEP6ss/LbFXf4dUudLShgBjBXtRmD6/dtmQz3wJL3naFeqveMDw== 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=ESYkjvsfCpo3j52ecVxj2NzakXhdAQw8+UZA/6NTDpk=; b=ZCiD6NQShVKixQzCHDLTWYTZxmPSMvWUX+kUn5lDbX0KJ6M7NsikwEfU4Z/o6IhltitpLSbGevxL/k5EJIHSVqHES12gIrIwiBnpoMbadW4KIe1nI1ua5rbQjBkVwifuhcwluTN1PkGFddRGasJp41pk0Tjt7iCqUiBHQvGptdqOR18rtE5aPgpTmzAjeJ+4OCmz2SJaXDX7lkFyVwHf/eCDQLz7l0Y1v4XzVMarbUo5rz95O0HGGp9CNYX0byCwvQITxNyg31w0dAfzAR3WBlJr/LgBd9wEjlIANnAzIms1Qmsur+tH9YBs+1JTQ8npIcPv+R5C4sRgujqM1mpnYw== 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=ESYkjvsfCpo3j52ecVxj2NzakXhdAQw8+UZA/6NTDpk=; b=lfOFEN1jEzO/nXc5ClDYriGu8kEn+cfqirTLUu4SoDw0+GO2sdfSIQRopoVLh94DRqSXAocMXhYSIClWbSmmaF/bwA9YnBbtyacIP7sGM0okujmsUnxLU65yA31/ZkHJ9UUUF3TcSXteyhVcPbCLGOlH8Nei1RbbzzkfzZ800ME= Received: from BL0PR0901MB4563.namprd09.prod.outlook.com (52.135.47.206) by BL0PR0901MB4355.namprd09.prod.outlook.com (52.135.47.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.19; Sat, 31 Aug 2019 04:46:14 +0000 Received: from BL0PR0901MB4563.namprd09.prod.outlook.com ([fe80::b532:35b9:abd0:ee7e]) by BL0PR0901MB4563.namprd09.prod.outlook.com ([fe80::b532:35b9:abd0:ee7e%4]) with mapi id 15.20.2220.013; Sat, 31 Aug 2019 04:46:14 +0000 From: "Sriram, Kotikalapudi (Fed)" To: The IESG , =?iso-8859-1?Q?=C9ric_Vyncke?= CC: "draft-ietf-opsec-urpf-improvements@ietf.org" , Sandra Murphy , "opsec-chairs@ietf.org" , Sandra Murphy , "opsec@ietf.org" , Warren Kumari Thread-Topic: =?iso-8859-1?Q?=C9ric_Vyncke's_No_Objection_on_draft-ietf-opsec-urpf-impr?= =?iso-8859-1?Q?ovements-03:_(with_COMMENT)?= Thread-Index: AQHVWCw3l+JDCHp1g06ot+mqkOpTCacUtlWA Date: Sat, 31 Aug 2019 04:46:13 +0000 Message-ID: References: <156639747640.25777.13888707111707970209.idtracker@ietfa.amsl.com> In-Reply-To: <156639747640.25777.13888707111707970209.idtracker@ietfa.amsl.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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.223.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 27061c6e-1614-43bb-8202-08d72dce2755 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BL0PR0901MB4355; x-ms-traffictypediagnostic: BL0PR0901MB4355: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 014617085B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39840400004)(346002)(376002)(136003)(396003)(199004)(189003)(81166006)(71190400001)(316002)(486006)(6506007)(99286004)(33656002)(110136005)(305945005)(6306002)(9686003)(7696005)(229853002)(966005)(54906003)(14454004)(478600001)(55016002)(76176011)(6246003)(74316002)(3846002)(6116002)(2906002)(71200400001)(8936002)(66066001)(11346002)(446003)(66946007)(102836004)(256004)(7736002)(6436002)(224303003)(53936002)(4326008)(5660300002)(26005)(52536014)(86362001)(81156014)(66446008)(66476007)(186003)(476003)(76116006)(66556008)(64756008)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR0901MB4355; H:BL0PR0901MB4563.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: s37WN6cwDq9zD9jU2J7yI3ImH2Br4/xMA+03ecG5ugdSkfs46jMRZUvOVAwbnG93fV4cViD5a8E7EmRniJyy3qzAR2AT/59UwAjLVK9Chs5PB3Mm15DuilCBknG70Sm5G2MECiXfn+3rxU3zx0cuVlaLsMJwXS0Jpejz+ye3lLif3k/Zbuv3RgDQ37xQZn1PaAe5LRV8trBQTTBmMrrHXVauYlJDj0N38LLfNgISXfz6fWBgQQMBNeEnSNjG8vzCcJcXUGqkr40l27c769bD9DQRKGDs7Z9H421yxoovPsbRRykeie3OimdmO79tt1YGcOVtKoaNOKZPm31pLAvCodxcVjclqpF6SF4wbxKKkOOnsTap5Nst7otBDSaslfYiITrZCA6V/euH8sHVQyWvAALi01r8G3Vd+XW6zHgvZck= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 27061c6e-1614-43bb-8202-08d72dce2755 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2019 04:46:13.9570 (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: 38QYwC29nji5IxFpE8cHqzuARMWyuK3K+tY7PXQpw9DoZ6SZDyRYBCip/YJ+MKcYztVH9zw69QH5reX+WIas2A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR0901MB4355 Archived-At: Subject: Re: [OPSEC] =?iso-8859-1?q?=C9ric_Vyncke=27s_No_Objection_on_draft-i?= =?iso-8859-1?q?etf-opsec-urpf-improvements-03=3A_=28with_COMMENT=29?= X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 04:46:22 -0000 Eric, Thank you for your comments. Sorry about the delay in replying. We have uploaded a new version and have included changes reflecting your comments. Please see: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-urpf-improvements-04= .txt =20 Please also see responses to your comments inline below.=20 -- Abstract -- >The abstract reads like 'promises' but not as a summary of the document. I= s >there any chance to add 2 lines summarizing the 'how' ? > Added some more wording in the abstract to address your comment. We have summarized the 'how' in the intro with a whole paragraph. Probably better not to make the abstract overly long. =20 >-- Section 1.1 -- >I am sure that by now you know that you have to use RFC 8174 boilerplate ;= -) > Yes. Done. >-- Section 2.2 -- >For completeness and symmetry with section 2.3, please explain which packe= ts >will be dropped. > Good catch. Done. >-- Section 2.3 -- >Suggestion: define "RPF list" before first use (even if mostly obvious). > >Please define "lateral peer" and why it is different to any other "peer". > Added Section 1.1. "Terminology" per your suggestion. We've provided definitions of these terms and more there. >-- Section 3.1 -- >Please define the "cone" used in this section. First time that I ever read= this >term and the RIPE paper does not explain it either (of course I am not a >routing expert). > Definition of customer cone is also included in the Terminology section 1.1= . >=3D=3D NITS =3D=3D > >-- Section 1 -- >Beside the intro, this section also introduces some terminology wording. M= ay I >suggest to have a (sub)section about "terminology" ? > Good suggestion. Done. >-- Section 2.1 -- >CMTS was introduced as an acronym but not DSLAM. > > Mention of DSLAM was not essential. So it is removed in the updated version= . Mention of CMTS, PDN-GW is sufficient in that context and they are introduced. Sriram From nobody Fri Aug 30 23:39:35 2019 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028DE1200E3; Fri, 30 Aug 2019 23:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-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=i04rpE+f; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=X6k6Uhzl 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 LS2r0cYAwPOm; Fri, 30 Aug 2019 23:39:16 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8BDC1200DE; Fri, 30 Aug 2019 23:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3458; q=dns/txt; s=iport; t=1567233555; x=1568443155; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sVbkq9WAvuW1lkthtKAiijgzauF6otLO7y5xm6ZDoi8=; b=i04rpE+fgcDQ0kRyWHiYn7QrUN9P4LKl0mXhRYt+MUWmYmVuVz999q3j uPNIUKw/ulq3ZoV1KSEuhuLovKWj6/uEiHrGzqbS8ABMG4Mw+Q3Zxei8N SHu7V1DC/4gWfsQUpGn6W11gkT2BCjf7vMxg5ZL+SR2AEg6e9O6Us1Lyh M=; IronPort-PHdr: =?us-ascii?q?9a23=3A4irA7RWT4s3gTtllsrHer2zUeMvV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA92J8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank3AtVEX1xo13q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuAAB0FWpd/49dJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZ4FFKScDbVYgBAsqhCGDRwOKdYI3mBGBQoEQA1QJAQEBDAE?= =?us-ascii?q?BJQgCAQGEPwIXgkkjOBMCAwgBAQQBAQECAQYEbYUuDIVLAgEDEhERDAEBKQk?= =?us-ascii?q?FAQ8CAQgaAiYCAgIwFQULAgQBDQUigwABJgGBQwMdAQIMojECgTiIYXOBMoJ?= =?us-ascii?q?8AQEFhQsYghYDBoEMKIt4GIFAP4ERJwwTgkw+gmECAgEXgS8YF4J0MoImjnc?= =?us-ascii?q?znG0Kgh+GcI1nG4IyhzaEHIpfgzeKO4dzkFECBAIEBQIOAQEFgWchgVhwFTs?= =?us-ascii?q?qAYJBgkI4gzqFFIU/cwGBKI4WAQE?= X-IronPort-AV: E=Sophos;i="5.64,449,1559520000"; d="scan'208";a="618276214" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Aug 2019 06:39:14 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x7V6dE8I029461 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 31 Aug 2019 06:39:14 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 31 Aug 2019 01:39:14 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 31 Aug 2019 01:39:13 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 31 Aug 2019 01:39:13 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IAMD4AOv5tzN6sbenZZdP/2omgp1n/d/YhLi2JDrmcOL201Nidu45uLasa2QeR103yaRJ7IqoIrWZZwKh+F8MNxGuDGfoBcVEd794Uh9RlFOi+Bl/r3TQic2eZzy5zTvE7o7uZnE+JWII5UgWzJ1O2UPa9ERqv515lUB6SS3a1OUpsyC+I28EymMdcvEJuYsgjGzyY1Q0OWkkBXgKst7mo2dQ4IouTWymD7oIV1ZEIun0ahjGT8celofZpM2lBrz1FHOJlfqisuPv1F/KUd+IgzqvhL4lZWGvG8ZEC++SuO1bjGL8VrVvhD8noS9Z0fPYkByNXQaLt0dlbWQns3BmQ== 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=sVbkq9WAvuW1lkthtKAiijgzauF6otLO7y5xm6ZDoi8=; b=TSfGYxTxJF/GcNFB+aHapUoR2kVy84JWcyXOIft2UzidvDeZ4/J5iiklqRbAC/WrUQBh3dzBUfmwVc7xJXqdIfgVIVnJIiCExNtFGH/7xMeaAEdvvslfn+ZCLEXuJl75r6r3zD3ezaf4JLRCrzpmAPoRsnUitNGIWjZo0zONwqjCApxvOGeobOWqlaK2m9KZYGpODtjjegNRrFMPWQdUrHu4eNv05TQ1+U/5bIoboiVixnD09vYSV2qia0E1naVAINNoCAgRRe/FpvTezJcodwg1asC8ohQel4wsyB4nbfUW+/Wt4/19Sn+d9HZn2Prm25wouLD+iWY3EfEeV6gRdw== 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=sVbkq9WAvuW1lkthtKAiijgzauF6otLO7y5xm6ZDoi8=; b=X6k6UhzlwIX5r5yWEOBacYgsfKYQkL64uCCV5tUlASTGOB3WufQVSaZ+sZ+8KWhezHT+uMKCu8Bz0V74iZK7m8bUksiXZp2Qx40+gcTIy99XgCQ55VfZdNWXn+QBfORJE3Vh4r1F1TLslrYSQQI0GBtEE2yfqxLhsXfpLwYlrCA= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB3904.namprd11.prod.outlook.com (10.255.180.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.20; Sat, 31 Aug 2019 06:39:11 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::d5c4:be39:66cb:449b]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::d5c4:be39:66cb:449b%6]) with mapi id 15.20.2199.021; Sat, 31 Aug 2019 06:39:11 +0000 From: "Eric Vyncke (evyncke)" To: "Sriram, Kotikalapudi (Fed)" , The IESG CC: "draft-ietf-opsec-urpf-improvements@ietf.org" , Sandra Murphy , "opsec-chairs@ietf.org" , "opsec@ietf.org" , Warren Kumari Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtb3Bz?= =?utf-8?Q?ec-urpf-improvements-03:_(with_COMMENT)?= Thread-Index: AQHVWCw3l+JDCHp1g06ot+mqkOpTCacUtlWAgABIcAA= Date: Sat, 31 Aug 2019 06:39:11 +0000 Message-ID: <26A374AE-5476-415C-B736-D1A08EA40B05@cisco.com> References: <156639747640.25777.13888707111707970209.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1c.0.190812 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:1cc7:aa56:5f89:fdc7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 49d88d5b-b560-4711-9a45-08d72dddeeea x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3904; x-ms-traffictypediagnostic: MN2PR11MB3904: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 014617085B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(136003)(376002)(366004)(39860400002)(199004)(189003)(58126008)(102836004)(110136005)(54906003)(6506007)(4326008)(6436002)(86362001)(486006)(6306002)(6512007)(316002)(446003)(224303003)(2906002)(11346002)(46003)(476003)(2616005)(36756003)(6246003)(53936002)(33656002)(6116002)(186003)(256004)(91956017)(76116006)(66946007)(81156014)(8936002)(81166006)(305945005)(66556008)(66476007)(7736002)(64756008)(66446008)(71200400001)(229853002)(71190400001)(5660300002)(6486002)(25786009)(966005)(478600001)(76176011)(99286004)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3904; H:MN2PR11MB4144.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-message-info: iX3Ux1KhMX2BUAcLIG47/KH82i60Kj0L6dsUjumNgGVBwHN8LVr5sdNg0LySyXUHXFfWQSaRlOb+DcTDx0idwLON9qiFLVmaXiLwKPPWvmwM8TSHHj0iqcE6Q6JOcwa1xRVkUh4+FzqZ7V2lhv0ITee6gmIuj301F5zoUWYtABA7gU0yG83+Oyjf1SBxD442daLLv3BS7QijUUYnBT+DdEOu20eKdVFe2InuUmjyzsGHj7hEokttYRvQnnut5l0ip2ntxpePImaRfF/+KmKUf8lBbJuwTLUc8ZN3nCL1iImCG1gGy5uWfDbdFbxGlqMU7GB90RacHSwHH33JYt5XAHli2rzbaLSo23nin5FVeQYz37bSfzhIQ+vEEbt5DY1qMOhA49ztqv4EQNIV1mpzHtkiwE6mdsFszaz4TIAzG2U= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <7C63B1E1C094BF49B18802FD126686F3@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 49d88d5b-b560-4711-9a45-08d72dddeeea X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2019 06:39:11.4189 (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: 36PRBxY7JhPy3HAsAhZ8FZcK7/3UzzBOn6A2kt0plrrna2wrlpk2Lj1eaef7K2HW5Kp2m6E0EWv0XOsJKeaS4A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3904 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xch-rcd-008.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [OPSEC] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-opsec-urpf-improvements-03=3A_=28with_COMMENT=29?= X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 06:39:21 -0000 VGhhbmsgeW91IFNyaXJhbSBmb3IgdGhlIHVwZGF0ZWQgZG9jdW1lbnQuDQoNCkp1c3QgYSBtaW5v ciBuaXQ6IGluIHRoZSB0ZXJtaW5vbG9neSBzZWN0aW9uLCBQMkMgYW5kIEMyUCBhcmUgaW4gdXBw ZXJjYXNlIGJ1dCBwMnAgaXMgaW4gbG93ZXIgY2FzZS4gVGhpcyBjYW4gYmUgZml4ZWQgbGF0ZXIg YXQgdGhlIEFVVEg0OCBzdGFnZQ0KDQotw6lyaWMNCg0K77u/T24gMzEvMDgvMjAxOSwgMDY6NDYs ICJTcmlyYW0sIEtvdGlrYWxhcHVkaSAoRmVkKSIgPGtvdGlrYWxhcHVkaS5zcmlyYW1AbmlzdC5n b3Y+IHdyb3RlOg0KDQogICAgRXJpYywNCiAgICANCiAgICBUaGFuayB5b3UgZm9yIHlvdXIgY29t bWVudHMuIFNvcnJ5IGFib3V0IHRoZSBkZWxheSBpbiByZXBseWluZy4NCiAgICBXZSBoYXZlIHVw bG9hZGVkIGEgbmV3IHZlcnNpb24gYW5kIGhhdmUgaW5jbHVkZWQgY2hhbmdlcw0KICAgIHJlZmxl Y3RpbmcgeW91ciBjb21tZW50cy4gUGxlYXNlIHNlZToNCiAgICBodHRwczovL3Rvb2xzLmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW9wc2VjLXVycGYtaW1wcm92ZW1lbnRzLTA0LnR4 dCAgDQogICAgUGxlYXNlIGFsc28gc2VlIHJlc3BvbnNlcyB0byB5b3VyIGNvbW1lbnRzIGlubGlu ZSBiZWxvdy4gDQogICAgDQogICAgLS0gQWJzdHJhY3QgLS0NCiAgICA+VGhlIGFic3RyYWN0IHJl YWRzIGxpa2UgJ3Byb21pc2VzJyBidXQgbm90IGFzIGEgc3VtbWFyeSBvZiB0aGUgZG9jdW1lbnQu IElzDQogICAgPnRoZXJlIGFueSBjaGFuY2UgdG8gYWRkIDIgbGluZXMgc3VtbWFyaXppbmcgdGhl ICdob3cnID8NCiAgICA+DQogICAgDQogICAgQWRkZWQgc29tZSBtb3JlIHdvcmRpbmcgaW4gdGhl IGFic3RyYWN0IHRvIGFkZHJlc3MgeW91ciBjb21tZW50Lg0KICAgIFdlIGhhdmUgc3VtbWFyaXpl ZCB0aGUgJ2hvdycgaW4gdGhlIGludHJvIHdpdGggYSB3aG9sZSBwYXJhZ3JhcGguDQogICAgUHJv YmFibHkgYmV0dGVyIG5vdCB0byBtYWtlIHRoZSBhYnN0cmFjdCBvdmVybHkgbG9uZy4NCiAgICAg DQogICAgPi0tIFNlY3Rpb24gMS4xIC0tDQogICAgPkkgYW0gc3VyZSB0aGF0IGJ5IG5vdyB5b3Ug a25vdyB0aGF0IHlvdSBoYXZlIHRvIHVzZSBSRkMgODE3NCBib2lsZXJwbGF0ZSA7LSkNCiAgICA+ DQogICAgDQogICAgWWVzLiBEb25lLg0KICAgIA0KICAgID4tLSBTZWN0aW9uIDIuMiAtLQ0KICAg ID5Gb3IgY29tcGxldGVuZXNzIGFuZCBzeW1tZXRyeSB3aXRoIHNlY3Rpb24gMi4zLCBwbGVhc2Ug ZXhwbGFpbiB3aGljaCBwYWNrZXRzDQogICAgPndpbGwgYmUgZHJvcHBlZC4NCiAgICA+DQogICAg DQogICAgR29vZCBjYXRjaC4gRG9uZS4NCiAgICANCiAgICA+LS0gU2VjdGlvbiAyLjMgLS0NCiAg ICA+U3VnZ2VzdGlvbjogZGVmaW5lICJSUEYgbGlzdCIgYmVmb3JlIGZpcnN0IHVzZSAoZXZlbiBp ZiBtb3N0bHkgb2J2aW91cykuDQogICAgPg0KICAgID5QbGVhc2UgZGVmaW5lICJsYXRlcmFsIHBl ZXIiIGFuZCB3aHkgaXQgaXMgZGlmZmVyZW50IHRvIGFueSBvdGhlciAicGVlciIuDQogICAgPg0K ICAgIA0KICAgIEFkZGVkIFNlY3Rpb24gMS4xLiAiVGVybWlub2xvZ3kiIHBlciB5b3VyIHN1Z2dl c3Rpb24uDQogICAgV2UndmUgcHJvdmlkZWQgZGVmaW5pdGlvbnMgb2YgdGhlc2UgdGVybXMgYW5k IG1vcmUgdGhlcmUuDQogICAgDQogICAgDQogICAgPi0tIFNlY3Rpb24gMy4xIC0tDQogICAgPlBs ZWFzZSBkZWZpbmUgdGhlICJjb25lIiB1c2VkIGluIHRoaXMgc2VjdGlvbi4gRmlyc3QgdGltZSB0 aGF0IEkgZXZlciByZWFkIHRoaXMNCiAgICA+dGVybSBhbmQgdGhlIFJJUEUgcGFwZXIgZG9lcyBu b3QgZXhwbGFpbiBpdCBlaXRoZXIgKG9mIGNvdXJzZSBJIGFtIG5vdCBhDQogICAgPnJvdXRpbmcg ZXhwZXJ0KS4NCiAgICA+DQogICAgDQogICAgRGVmaW5pdGlvbiBvZiBjdXN0b21lciBjb25lIGlz IGFsc28gaW5jbHVkZWQgaW4gdGhlIFRlcm1pbm9sb2d5IHNlY3Rpb24gMS4xLg0KICAgIA0KICAg IA0KICAgID49PSBOSVRTID09DQogICAgPg0KICAgID4tLSBTZWN0aW9uIDEgLS0NCiAgICA+QmVz aWRlIHRoZSBpbnRybywgdGhpcyBzZWN0aW9uIGFsc28gaW50cm9kdWNlcyBzb21lIHRlcm1pbm9s b2d5IHdvcmRpbmcuIE1heSBJDQogICAgPnN1Z2dlc3QgdG8gaGF2ZSBhIChzdWIpc2VjdGlvbiBh Ym91dCAidGVybWlub2xvZ3kiID8NCiAgICA+DQogICAgDQogICAgR29vZCBzdWdnZXN0aW9uLiBE b25lLg0KICAgIA0KICAgID4tLSBTZWN0aW9uIDIuMSAtLQ0KICAgID5DTVRTIHdhcyBpbnRyb2R1 Y2VkIGFzIGFuIGFjcm9ueW0gYnV0IG5vdCBEU0xBTS4NCiAgICA+DQogICAgPg0KICAgIE1lbnRp b24gb2YgRFNMQU0gd2FzIG5vdCBlc3NlbnRpYWwuIFNvIGl0IGlzIHJlbW92ZWQgaW4gdGhlIHVw ZGF0ZWQgdmVyc2lvbi4NCiAgICBNZW50aW9uIG9mIENNVFMsIFBETi1HVyBpcyBzdWZmaWNpZW50 IGluIHRoYXQgY29udGV4dA0KICAgIGFuZCB0aGV5IGFyZSBpbnRyb2R1Y2VkLg0KICAgIA0KICAg IFNyaXJhbQ0KICAgIA0KDQo= From nobody Sat Aug 31 12:57:59 2019 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE239120105; Sat, 31 Aug 2019 12:57:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 SgjLMgS3KaWm; Sat, 31 Aug 2019 12:57:48 -0700 (PDT) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2107.outbound.protection.outlook.com [40.107.91.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B92D12008F; Sat, 31 Aug 2019 12:57:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ns2JMb9vj23XtnQTI6mmAcZrwgDp6hCojNJ88t+zsEfs44VeSphbKSEn4/7dmNLMq3uWS2mokCD6o5zPSCsPieU8Ts/OOWwu3Vc1Dd09Xj/tL22XUM1WZ8WopVFcFm53VKGjye6ZbWwDIlH5JLONb5xu4CB2GtD8HRiveCEurDLMwSjrIlY82z88MCGO8oXhKi2XJn+nX7Z6aVr3XcVI+SYfx+PDrVLx1AOakhg3DoDjnhAklpffeVg37uGq9Gx4jtcZUXpYx7AU3333xDrmAqQrb7ANh6hdZeMuEczMjt9wEnIurS+zRUDXnfi9VZE5wCmBDP7D0iR5ODFQTSH8BA== 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=f4B4HqlFpgbJFclnN1NfdJ4KzIjddg7/ewjpupTy6Us=; b=c8za++W1/OiedzrMtZUCdK8XHm6xNsNiLrI2FiGfO+YvcgMSuTQK7e/l/UGZpKQRFItsiSA/u3lDKm0Zo2sJWot69Wfqe8Xv6k/QxEXUew2Ldn48R+YDiFvuoMw4cUWz8PQGcXvZfxfQaetGc5k70C24ZUtGeF/eLXDX2ple+zE4cXm2F3Yl2N772ifSE6ACTdx8n9L9lwoIJm7dfZZYhhPJhprmhcygcmkqwPoC9mi226bR0qM8u9AFfj4/AqiCTkyHN05jzQN/wbUy+m+PlegLOMMz039c1GsUrA35piFK3DTGeALlLrIkOI+4TGhFuW7UB573UjtP9k7CU8XKKQ== 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=f4B4HqlFpgbJFclnN1NfdJ4KzIjddg7/ewjpupTy6Us=; b=iClF1j/oQIQ2X0+UTPvtlsLpxuDM0jybVJrrsPkzt7mKUK8M+hc0dgDEqlNe23Fpd8jRoZ+li9QLP2cmR35MVZ0xO3E+riRihXv8OTcMNlxrrMTDywqNTIgTMDE6JPoPt2O7E11S+OZgv+Rbl+jV78/ZAZ2bm4HfktGalH7NPpI= Received: from BL0PR0901MB4563.namprd09.prod.outlook.com (52.135.47.206) by BL0PR0901MB3154.namprd09.prod.outlook.com (20.177.242.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Sat, 31 Aug 2019 19:43:22 +0000 Received: from BL0PR0901MB4563.namprd09.prod.outlook.com ([fe80::b532:35b9:abd0:ee7e]) by BL0PR0901MB4563.namprd09.prod.outlook.com ([fe80::b532:35b9:abd0:ee7e%4]) with mapi id 15.20.2220.013; Sat, 31 Aug 2019 19:43:22 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "Eric Vyncke (evyncke)" , The IESG CC: "draft-ietf-opsec-urpf-improvements@ietf.org" , Sandra Murphy , "opsec-chairs@ietf.org" , "opsec@ietf.org" , Warren Kumari Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtb3Bz?= =?utf-8?Q?ec-urpf-improvements-03:_(with_COMMENT)?= Thread-Index: AQHVWCw3l+JDCHp1g06ot+mqkOpTCacUtlWAgABIcACAALQ10Q== Date: Sat, 31 Aug 2019 19:43:22 +0000 Message-ID: References: <156639747640.25777.13888707111707970209.idtracker@ietfa.amsl.com> , <26A374AE-5476-415C-B736-D1A08EA40B05@cisco.com> In-Reply-To: <26A374AE-5476-415C-B736-D1A08EA40B05@cisco.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=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.220.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8266ed40-6d5d-4d93-e933-08d72e4b7b46 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BL0PR0901MB3154; x-ms-traffictypediagnostic: BL0PR0901MB3154: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 014617085B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(346002)(39850400004)(366004)(396003)(189003)(199004)(14454004)(45080400002)(4326008)(53546011)(86362001)(55016002)(6506007)(6306002)(224303003)(102836004)(26005)(186003)(81156014)(5660300002)(316002)(52536014)(7736002)(76176011)(81166006)(9686003)(7696005)(25786009)(71200400001)(71190400001)(229853002)(76116006)(53936002)(66946007)(476003)(66476007)(74316002)(966005)(478600001)(66446008)(54906003)(8936002)(99286004)(64756008)(486006)(66556008)(2906002)(3846002)(6116002)(6246003)(256004)(446003)(6436002)(66066001)(110136005)(305945005)(33656002)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR0901MB3154; H:BL0PR0901MB4563.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: aAft6uGd1AscBu8Z/7WwPfJ3DwHjglpgLKhtuKb/ooUgxPZVqDrkiTNWRUU2QyL7KHgCdBy0YxrJtVpOt5zqFpFJNw4XcFsPi7eIj16KWjTKKgSc6QDnvaOpx9usFMlVyQrJkHOY+qbFqwU28spCGtY9aOSl+oNL5KnjxIeC6rk29TT2pLDpprinSM/0NyhfnZ7w7wQoK2DRUiKhKY/F654xK0Cxdbghbd9tFiYVTyZgeDWMbFWRd6rjH0fmbi0AmEFlFvpkMFrmhFygBQt4h4W42vAMf/jHJGPuo7sXGv5SfNLj8ljO5ZGZXqpbnHvC9l3hm2/JSAJaMN3jV23K1ylPg8wLYm2W1QTuip2Px8tBE/nWbD1xiwP79K4hxYVksQTFstuRLWaJ2lPzd2z2HfMDpXyZ7/ARy3xJr99DCt4= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 8266ed40-6d5d-4d93-e933-08d72e4b7b46 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2019 19:43:22.1013 (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: F9ymmk4ptnDCJ61MiJelchCsAJlQbPbdJWbCcDkJ0ghWFoja5FxtMvPxRw4yTcbE7g+w60tjw/AV1rz+54RTdg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR0901MB3154 Archived-At: Subject: Re: [OPSEC] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-opsec-urpf-improvements-03=3A_=28with_COMMENT=29?= X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 19:57:51 -0000 Pkp1c3QgYSBtaW5vciBuaXQ6IGluIHRoZSB0ZXJtaW5vbG9neSBzZWN0aW9uLCBQMkMgYW5kIEMy UCBhcmUgaW4gdXBwZXJjYXNlIGJ1dCBwMnAgaXMgaW4gbG93ZXIgY2FzZS4gVGhpcyBjYW4gYmUg Zml4ZWQgbGF0ZXIgYXQgdGhlIEFVVEg0OCBzdGFnZSANCg0KVGhlIHAgaW4gcDJwIChwZWVyLXRv LXBlZXIpIGlzIGxvd2VyIGNhc2Ugb24gcHVycG9zZS4NCldlIGhhdmUgdXBwZXIgY2FzZSBQIGZv ciBQcm92aWRlci4NClNvIHdlIHVzZSBsb3dlciBjYXNlIHAgaW4gcDJwIHdoZXJlIG5laXRoZXIg aXMgcHJvdmlkZXIgKGluIHRoZSBtdXR1YWwgcmVsYXRpb25zaGlwKSwgDQppbnN0ZWFkIHRoZSB0 d28gQVNlcyBhcmUgbGF0ZXJhbCBwZWVycyB0byBlYWNoIG90aGVyLiANCg0KU3JpcmFtIA0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogRXJpYyBWeW5ja2Ug KGV2eW5ja2UpIDxldnluY2tlQGNpc2NvLmNvbT4NClNlbnQ6IFNhdHVyZGF5LCBBdWd1c3QgMzEs IDIwMTkgMjozOSBBTQ0KVG86IFNyaXJhbSwgS290aWthbGFwdWRpIChGZWQpOyBUaGUgSUVTRw0K Q2M6IGRyYWZ0LWlldGYtb3BzZWMtdXJwZi1pbXByb3ZlbWVudHNAaWV0Zi5vcmc7IFNhbmRyYSBN dXJwaHk7IG9wc2VjLWNoYWlyc0BpZXRmLm9yZzsgb3BzZWNAaWV0Zi5vcmc7IFdhcnJlbiBLdW1h cmkNClN1YmplY3Q6IFJlOiDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0 Zi1vcHNlYy11cnBmLWltcHJvdmVtZW50cy0wMzogKHdpdGggQ09NTUVOVCkNCg0KVGhhbmsgeW91 IFNyaXJhbSBmb3IgdGhlIHVwZGF0ZWQgZG9jdW1lbnQuDQoNCkp1c3QgYSBtaW5vciBuaXQ6IGlu IHRoZSB0ZXJtaW5vbG9neSBzZWN0aW9uLCBQMkMgYW5kIEMyUCBhcmUgaW4gdXBwZXJjYXNlIGJ1 dCBwMnAgaXMgaW4gbG93ZXIgY2FzZS4gVGhpcyBjYW4gYmUgZml4ZWQgbGF0ZXIgYXQgdGhlIEFV VEg0OCBzdGFnZQ0KDQotw6lyaWMNCg0K77u/T24gMzEvMDgvMjAxOSwgMDY6NDYsICJTcmlyYW0s IEtvdGlrYWxhcHVkaSAoRmVkKSIgPGtvdGlrYWxhcHVkaS5zcmlyYW1AbmlzdC5nb3Y+IHdyb3Rl Og0KDQogICAgRXJpYywNCg0KICAgIFRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50cy4gU29ycnkg YWJvdXQgdGhlIGRlbGF5IGluIHJlcGx5aW5nLg0KICAgIFdlIGhhdmUgdXBsb2FkZWQgYSBuZXcg dmVyc2lvbiBhbmQgaGF2ZSBpbmNsdWRlZCBjaGFuZ2VzDQogICAgcmVmbGVjdGluZyB5b3VyIGNv bW1lbnRzLiBQbGVhc2Ugc2VlOg0KICAgIGh0dHBzOi8vZ2NjMDEuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGcmZjZGlm ZiUzRnVybDIlM0RkcmFmdC1pZXRmLW9wc2VjLXVycGYtaW1wcm92ZW1lbnRzLTA0LnR4dCZhbXA7 ZGF0YT0wMiU3QzAxJTdDa290aWthbGFwdWRpLnNyaXJhbSU0MG5pc3QuZ292JTdDMWY4MzI3NmQ4 ZDYzNDkyMTlmODUwOGQ3MmRkZGYyY2MlN0MyYWI1ZDgyZmQ4ZmE0Nzk3YTkzZTA1NDY1NWM2MWRl YyU3QzElN0MwJTdDNjM3MDI4MzAzNTk4OTIwOTk1JmFtcDtzZGF0YT1zcnZxWExESEVubEl3b0la QXBHR0hjVkFRSkRmVXhRYjFuNjBkakhsaWtVJTNEJmFtcDtyZXNlcnZlZD0wDQogICAgUGxlYXNl IGFsc28gc2VlIHJlc3BvbnNlcyB0byB5b3VyIGNvbW1lbnRzIGlubGluZSBiZWxvdy4NCg0KICAg IC0tIEFic3RyYWN0IC0tDQogICAgPlRoZSBhYnN0cmFjdCByZWFkcyBsaWtlICdwcm9taXNlcycg YnV0IG5vdCBhcyBhIHN1bW1hcnkgb2YgdGhlIGRvY3VtZW50LiBJcw0KICAgID50aGVyZSBhbnkg Y2hhbmNlIHRvIGFkZCAyIGxpbmVzIHN1bW1hcml6aW5nIHRoZSAnaG93JyA/DQogICAgPg0KDQog ICAgQWRkZWQgc29tZSBtb3JlIHdvcmRpbmcgaW4gdGhlIGFic3RyYWN0IHRvIGFkZHJlc3MgeW91 ciBjb21tZW50Lg0KICAgIFdlIGhhdmUgc3VtbWFyaXplZCB0aGUgJ2hvdycgaW4gdGhlIGludHJv IHdpdGggYSB3aG9sZSBwYXJhZ3JhcGguDQogICAgUHJvYmFibHkgYmV0dGVyIG5vdCB0byBtYWtl IHRoZSBhYnN0cmFjdCBvdmVybHkgbG9uZy4NCg0KICAgID4tLSBTZWN0aW9uIDEuMSAtLQ0KICAg ID5JIGFtIHN1cmUgdGhhdCBieSBub3cgeW91IGtub3cgdGhhdCB5b3UgaGF2ZSB0byB1c2UgUkZD IDgxNzQgYm9pbGVycGxhdGUgOy0pDQogICAgPg0KDQogICAgWWVzLiBEb25lLg0KDQogICAgPi0t IFNlY3Rpb24gMi4yIC0tDQogICAgPkZvciBjb21wbGV0ZW5lc3MgYW5kIHN5bW1ldHJ5IHdpdGgg c2VjdGlvbiAyLjMsIHBsZWFzZSBleHBsYWluIHdoaWNoIHBhY2tldHMNCiAgICA+d2lsbCBiZSBk cm9wcGVkLg0KICAgID4NCg0KICAgIEdvb2QgY2F0Y2guIERvbmUuDQoNCiAgICA+LS0gU2VjdGlv biAyLjMgLS0NCiAgICA+U3VnZ2VzdGlvbjogZGVmaW5lICJSUEYgbGlzdCIgYmVmb3JlIGZpcnN0 IHVzZSAoZXZlbiBpZiBtb3N0bHkgb2J2aW91cykuDQogICAgPg0KICAgID5QbGVhc2UgZGVmaW5l ICJsYXRlcmFsIHBlZXIiIGFuZCB3aHkgaXQgaXMgZGlmZmVyZW50IHRvIGFueSBvdGhlciAicGVl ciIuDQogICAgPg0KDQogICAgQWRkZWQgU2VjdGlvbiAxLjEuICJUZXJtaW5vbG9neSIgcGVyIHlv dXIgc3VnZ2VzdGlvbi4NCiAgICBXZSd2ZSBwcm92aWRlZCBkZWZpbml0aW9ucyBvZiB0aGVzZSB0 ZXJtcyBhbmQgbW9yZSB0aGVyZS4NCg0KDQogICAgPi0tIFNlY3Rpb24gMy4xIC0tDQogICAgPlBs ZWFzZSBkZWZpbmUgdGhlICJjb25lIiB1c2VkIGluIHRoaXMgc2VjdGlvbi4gRmlyc3QgdGltZSB0 aGF0IEkgZXZlciByZWFkIHRoaXMNCiAgICA+dGVybSBhbmQgdGhlIFJJUEUgcGFwZXIgZG9lcyBu b3QgZXhwbGFpbiBpdCBlaXRoZXIgKG9mIGNvdXJzZSBJIGFtIG5vdCBhDQogICAgPnJvdXRpbmcg ZXhwZXJ0KS4NCiAgICA+DQoNCiAgICBEZWZpbml0aW9uIG9mIGN1c3RvbWVyIGNvbmUgaXMgYWxz byBpbmNsdWRlZCBpbiB0aGUgVGVybWlub2xvZ3kgc2VjdGlvbiAxLjEuDQoNCg0KICAgID49PSBO SVRTID09DQogICAgPg0KICAgID4tLSBTZWN0aW9uIDEgLS0NCiAgICA+QmVzaWRlIHRoZSBpbnRy bywgdGhpcyBzZWN0aW9uIGFsc28gaW50cm9kdWNlcyBzb21lIHRlcm1pbm9sb2d5IHdvcmRpbmcu IE1heSBJDQogICAgPnN1Z2dlc3QgdG8gaGF2ZSBhIChzdWIpc2VjdGlvbiBhYm91dCAidGVybWlu b2xvZ3kiID8NCiAgICA+DQoNCiAgICBHb29kIHN1Z2dlc3Rpb24uIERvbmUuDQoNCiAgICA+LS0g U2VjdGlvbiAyLjEgLS0NCiAgICA+Q01UUyB3YXMgaW50cm9kdWNlZCBhcyBhbiBhY3JvbnltIGJ1 dCBub3QgRFNMQU0uDQogICAgPg0KICAgID4NCiAgICBNZW50aW9uIG9mIERTTEFNIHdhcyBub3Qg ZXNzZW50aWFsLiBTbyBpdCBpcyByZW1vdmVkIGluIHRoZSB1cGRhdGVkIHZlcnNpb24uDQogICAg TWVudGlvbiBvZiBDTVRTLCBQRE4tR1cgaXMgc3VmZmljaWVudCBpbiB0aGF0IGNvbnRleHQNCiAg ICBhbmQgdGhleSBhcmUgaW50cm9kdWNlZC4NCg0KICAgIFNyaXJhbQ0KDQoNCg==