Re: [Sidrops] WGLC for draft-ietf-sidrops-ov-clarify-00

"Montgomery, Douglas (Fed)" <dougm@nist.gov> Thu, 29 March 2018 19:01 UTC

Return-Path: <dougm@nist.gov>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1011412E03C for <sidrops@ietfa.amsl.com>; Thu, 29 Mar 2018 12:01:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=nistgov.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 SVn03l02__iu for <sidrops@ietfa.amsl.com>; Thu, 29 Mar 2018 12:01:24 -0700 (PDT)
Received: from GCC01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0114.outbound.protection.outlook.com [23.103.200.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AAAA12E04A for <sidrops@ietf.org>; Thu, 29 Mar 2018 12:00:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JqBNNA3PZaDdO3OIpbcx9HxbiWuxOQxurUnnehw+7PM=; b=Znck8+uQcP6Jzzg8OT3SDxO2+ZnzL72GrIUdi9ZsbNr/BVxOEDWqPIt/3Vi+mSaz+VWSrRGcrWERLhKbUpB9se3pA0XBoUFA6Z2jeLXGJmChjIDlOZee7nSAg2OGleEqkyj7eDrjYqKR/8uiEvpUaSotmUo/QRYuLQ0TV2+YnmE=
Received: from DM5PR0901MB2504.namprd09.prod.outlook.com (52.132.128.29) by DM5PR0901MB2502.namprd09.prod.outlook.com (52.132.128.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.609.10; Thu, 29 Mar 2018 19:00:53 +0000
Received: from DM5PR0901MB2504.namprd09.prod.outlook.com ([fe80::9488:d152:3866:11a]) by DM5PR0901MB2504.namprd09.prod.outlook.com ([fe80::9488:d152:3866:11a%13]) with mapi id 15.20.0609.012; Thu, 29 Mar 2018 19:00:53 +0000
From: "Montgomery, Douglas (Fed)" <dougm@nist.gov>
To: Keyur Patel <keyur@arrcus.com>, "sidrops@ietf.org" <sidrops@ietf.org>
Thread-Topic: [Sidrops] WGLC for draft-ietf-sidrops-ov-clarify-00
Thread-Index: AQHTx5BCLLXyyccDFEGWb9Niqjyh2A==
Date: Thu, 29 Mar 2018 19:00:53 +0000
Message-ID: <554BE4EF-D381-4CF1-923D-4E38F494915E@nist.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.b.0.180311
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dougm@nist.gov;
x-originating-ip: [2610:20:6222:140:b150:c0ec:a8e9:87b1]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR0901MB2502; 7:PIelohserh67Pj0cYckRc+I6tcUQMn5WqwR1qLwJrjckSs6nJK5l9JZEydsshJzhdF219rPh7uy8HiS8aKpCCjRKehPlJTE7wC/iyfz3gg+WCLo5KbFmq7DYUA0WmEoDrUflz1m4evhtV8hM9KdNZDQUIS+iFa4Ygtm8BaqPJ+n8lJaO4n32kxIte+Cx5QDHxZsdefxvwlCHlmgXGbdpeudoS4d6LLQL0Ir1VFu1Abw+WULfo4NTs+y54bfkLhwY
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 210cb608-e34f-4098-72cd-08d595a76584
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DM5PR0901MB2502;
x-ms-traffictypediagnostic: DM5PR0901MB2502:
x-microsoft-antispam-prvs: <DM5PR0901MB2502193E4A53C40D0A868319DEA20@DM5PR0901MB2502.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(189930954265078)(219752817060721)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231221)(944501327)(52105095)(6055026)(6041310)(20161123560045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR0901MB2502; BCL:0; PCL:0; RULEID:; SRVR:DM5PR0901MB2502;
x-forefront-prvs: 0626C21B10
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(366004)(39860400002)(39380400002)(199004)(189003)(7736002)(5660300001)(86362001)(99286004)(6512007)(54896002)(53546011)(6506007)(966005)(2900100001)(6246003)(46003)(6486002)(486005)(83716003)(186003)(68736007)(236005)(6436002)(486005)(106356001)(606006)(6306002)(8936002)(102836004)(82746002)(25786009)(53936002)(5250100002)(36756003)(33656002)(6116002)(3280700002)(58126008)(97736004)(2906002)(81156014)(81166006)(8676002)(14454004)(105586002)(3660700001)(2616005)(110136005)(229853002)(2501003)(476003)(316002)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR0901MB2502; H:DM5PR0901MB2504.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
x-microsoft-antispam-message-info: UJzmfLf4qI9aaS66FCl2a31B4JzNAuRSxdy1iUEHErVrl1ssmdwvp9iovGWLEQxCkI74L/ZMDL10c69Z2iP1cM86IyEUSYOSKq4qvXTCqHqY8WU8H66KFtFaeahQeQECufQrKDgdWc9WhcmxAh5IXy1GibhAdTkG4baccTR7aO6HQMUo1jWfGm4lHHc31zsGsNATQT8tOQ7+0FJN+uEVBqjEztKiPE0bt3EKv9h81zI3mEXfjJcL5Ez9HbPjO3f3OK0rhmUwul4b1DqoWw/X8cH0m3EJ3hEfcfwK2YkH0JrGLmFwrg9qHiYMTv6WEOk7fSzNoXz8II66d0abEPiihw==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_554BE4EFD3814CF1923D4E38F494915Enistgov_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-Network-Message-Id: 210cb608-e34f-4098-72cd-08d595a76584
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2018 19:00:53.7736 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0901MB2502
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/FfRG4Kfb2uNEdwUp37h7rPG_mm0>
Subject: Re: [Sidrops] WGLC for draft-ietf-sidrops-ov-clarify-00
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2018 19:01:27 -0000

Sorry for being late on the call for comments, but I have a question about the draft and the implications for OV that I wanted to discuss.

The new draft makes it clear that routes that originate internal to an AS that get distributed into iBGP MUST be marked by default.


“ This means that, on a router, all routes in BGP, absent operator
   configuration otherwise, MUST have been marked because they were
   either received via BGP (whether eBGP or iBGP), redistributed from an
   IGP, static, or directly connected, or any other distribution into
   BGP.

   When redistributing into BGP from connected, static, IGP, iBGP, etc.,
   there is no AS_PATH in the input to allow RPKI validation of the
   originating AS.  In such cases, the router SHOULD use the AS of the
   router's BGP configuration.”

In a situation where internal more specific routes are redistributed into iBGP for use internal to the AS, but summarized into an aggregate before being originated in eBGP, and the ROA for the eBGP aggregate is set tight (e.g., equal to the aggregate length), how do we suggest this is to be handled?

For example I use /24s internally, but only originate a /16 externally, and have a ROA with MaxLength=16.   Without further configuration/action this would result in the internal /24s would be marked Invalid, but clearly I don’t want them to be deprefed or dropped.

The choices seem to be that I have the ability to write route policy that exempts local routes from the an overall policy (e.g., drop invalid, unless it is a locally generated iBGP route), or I create SLURM entries to make the /24s valid, only in my AS, but not in the public RPKI data?   Either of these choices has some configuration complexity.

Are there other ways of handling this.   Do implementations provide enough policy knobs to allow me to apply OV policies to some iBGP routes, but not others (e.g., locally originated)?

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

From: Sidrops <sidrops-bounces@ietf.org> on behalf of Keyur Patel <keyur@arrcus.com>
Date: Wednesday, February 28, 2018 at 4:04 PM
To: "sidrops@ietf.org" <sidrops@ietf.org>
Subject: [Sidrops] WGLC for draft-ietf-sidrops-ov-clarify-00

The draft can be found at: https://datatracker.ietf.org/doc/draft-ietf-sidrops-ov-clarify/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-sidrops-ov-clarify%2F&data=02%7C01%7Cdougm%40nist.gov%7C568a00049ec0477f3e9a08d57eeed716%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636554486639810261&sdata=qdbUfO9UmUil0ifJi591o%2F8cIVY2L5%2BaGoQc0PF59rA%3D&reserved=0>.