Re: [Sidrops] WGLC for draft-ietf-sidrops-ov-egress-00.txt - ENDS 11/25/2019 (November 25 2019)

"Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov> Wed, 27 November 2019 21:10 UTC

Return-Path: <kotikalapudi.sriram@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 5712E120A9D; Wed, 27 Nov 2019 13:10:45 -0800 (PST)
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, HTML_MESSAGE=0.001, 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 oXcxKWUI8kJQ; Wed, 27 Nov 2019 13:10:42 -0800 (PST)
Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2096.outbound.protection.outlook.com [40.107.89.96]) (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 26840120A97; Wed, 27 Nov 2019 13:10:41 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ieHy5Y6SrplaKq63Yo7tn1HoimLRh5Vx6BOvHZUrz2ki1lxNN+TvYdpxdZEhot7wmX71EJY+nmuiVZCpMdOY/eMZmY3Dv3igoX2qJWpGngv0ar9/0LVXIV6/urdp+y2gdSHNnVAQ5bAzNkZxbNSz8jKXORhG0e7yG13AcNLiwfK0epQ16/BMx9iKNaw9hVsONsD+02tKNHxjSrkwNMcI28kP/ZjG3CS51Stqme+0QXJFGIxtPwjyOFo8zkXvQL8U0OFZ3PcWpLGzzJrMeyHSmKFpt4hHu/GG6Ej15ZdmyqZsaxVlXhDZmHSPAbBIXD2pFsANSerbtr1mffu+kXLMnw==
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=V8XKTgdTEFHY7NzEG4an90k2RM82++LgIB7v8SnV5cA=; b=PVTyg47RFCFc5MGZBXE8tObLNYVSWdDb1otlaJaSSBBBQCrU13GSl6vjitEGf7OUaWD9viXGOWdf3MmKLC5S/l8si2NZJAWS7cybgzwBScR+yYx2NsxxEqro7mFi9zMdivylXzFDWgb4Kj+MPxHRlaelqpQHw08cZ/odsNjCzkN5MMsErLuLB+g0Xs8MSVVlj6frTKqu4FDRZpz1v3B5HJaxcrIO0hTRBwqvSHdjnGrFU9vX6H7cDepW6JacrdRGBmCwTRY0F0dLRlBo28ogRkX/3Lmy5SYlmrTpL/CAQqlXn05w7uiQvTrTAHZldHKjWtYO1O+4zvKiYDW/fos9wg==
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=V8XKTgdTEFHY7NzEG4an90k2RM82++LgIB7v8SnV5cA=; b=eMCniqovZl4JNRX4usrIJWZyv6xO2z/EPzUxFCetNTq/dANkXReT32+NrbC6W5AEpWNPUADP+rUee5u305lT1YC/W4Oq92tsB3yuuQY8aIPqcq4MXBPZTWtoOdWErR/1R+RAO98YbESkW+pn0DgvGO2hP4KHPSEU/55EuNukNpc=
Received: from DM6PR09MB3386.namprd09.prod.outlook.com (20.179.51.19) by DM6PR09MB4728.namprd09.prod.outlook.com (20.180.63.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.18; Wed, 27 Nov 2019 21:10:39 +0000
Received: from DM6PR09MB3386.namprd09.prod.outlook.com ([fe80::3dc8:c3a3:e7eb:e1ed]) by DM6PR09MB3386.namprd09.prod.outlook.com ([fe80::3dc8:c3a3:e7eb:e1ed%4]) with mapi id 15.20.2474.023; Wed, 27 Nov 2019 21:10:39 +0000
From: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
To: "sidrops@ietf.org" <sidrops@ietf.org>
CC: "sidrops-chairs@ietf.org" <sidrops-chairs@ietf.org>, "draft-ietf-sidrops-ov-egress@ietf.org" <draft-ietf-sidrops-ov-egress@ietf.org>, Jeffrey Haas <jhaas@pfrc.org>
Thread-Topic: Re: [Sidrops] WGLC for draft-ietf-sidrops-ov-egress-00.txt - ENDS 11/25/2019 (November 25 2019)
Thread-Index: AdWlYJlH7zTPSpSNSfi1p6IGuq6Tdg==
Date: Wed, 27 Nov 2019 21:10:38 +0000
Message-ID: <DM6PR09MB3386A1201CE90B01159DDA2C84440@DM6PR09MB3386.namprd09.prod.outlook.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.140.161]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 83eae383-b844-44de-29d9-08d7737e4112
x-ms-traffictypediagnostic: DM6PR09MB4728:|DM6PR09MB4728:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DM6PR09MB472841CE32D55DE102569EBB84440@DM6PR09MB4728.namprd09.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 023495660C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(39860400002)(376002)(346002)(366004)(199004)(189003)(76116006)(66556008)(26005)(66476007)(64756008)(66946007)(66446008)(5660300002)(52536014)(102836004)(14454004)(186003)(316002)(6506007)(7696005)(71190400001)(71200400001)(54906003)(7736002)(2501003)(74316002)(81156014)(478600001)(229853002)(3846002)(6306002)(256004)(6916009)(54896002)(55016002)(8676002)(81166006)(2351001)(33656002)(8936002)(86362001)(99286004)(66066001)(6116002)(790700001)(5640700003)(6246003)(4326008)(25786009)(2906002)(9686003)(6436002)(1730700003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR09MB4728; H:DM6PR09MB3386.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: BCL:0;
x-microsoft-antispam-message-info: gR2sSVVergWZsh7b5b2kiGD8PujygSZg2JSO7AYFXVVUqvhgkVuTTYsrA1NKHnpS+lwHwBn4eZRcaEmmTn2dADvEhltUqTBnhai9S9QwGFCbRjb6ffLzpwiQAljLxCEOj/O42u8FOj9kTLm0csmVCk7TbmXlW1NFxUQQqS0jA2NqkUXTHpJZC2Y47WwjhU0PHYhGLN+sobMo0uwVo/Rc2TlUvJ8Fq0dZEAV2k5Iod+IGPOsfS8yTqlU7HcnwLaBknPzPmobMojqy9uRnIskUwOpfHbzf+ezeqsdiP6+KNL4nJzsOBpIFFQL5X3VGddUQ/C7tTOfH+AnVgBYV1QexqCK2LVx+OtSimRDqAWqoY1AkKJUzOJJ8z9ZJ4qD5pGOrt3fjRVzb+okIu463kDLsebeMWHr4hG1xf7/2QifpKfHQMUqHK6t7AbqpJ9F7kLal
Content-Type: multipart/alternative; boundary="_000_DM6PR09MB3386A1201CE90B01159DDA2C84440DM6PR09MB3386namp_"
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-Network-Message-Id: 83eae383-b844-44de-29d9-08d7737e4112
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2019 21:10:39.0647 (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: KZ6YbOM/6Am0/Vyw3PsYDEjIqlMp04FvPnTXhtvxSJvwgG4CozZbDEv+fX2lJL/A4IuHq8hZPhUX+8RYvEJEGw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR09MB4728
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/5JHfCna0DcYNCHDVks3wKAz_4fc>
Subject: Re: [Sidrops] WGLC for draft-ietf-sidrops-ov-egress-00.txt - ENDS 11/25/2019 (November 25 2019)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Nov 2019 21:10:45 -0000

I think the draft should make a recommendation that
the AS must create a ROA in the first place for the
prefix with the correct origin AS that will result
after the policies are applied.

I feel that the following paragraph in the draft is fuzzy/incorrect.

   "Configurations may have complex policy where the final announced
   origin AS may not be easily predicted before all policies have been
   run.  Therefore it SHOULD be possible to specify an origin validation
   policy which MUST BE run after such non-deterministic policies."

Is there such a thing as non-deterministic policy?
What does it mean to say that the outcome of applying
one or a set of policies is that it results in
a random AS being the origin AS?
Or, to say that the origin AS is not predictable?
Well, if it cannot be predicted then the sending AS under
consideration is not in a position to create
the ROA that is necessary. This cannot be.

Suggested text (or some variation of it):
The operator MUST determine the origin AS
based on policies that are applied on egress, and
MUST create a ROA accordingly.
The sending BGP speaker MUST perform origin validation
at egress (i.e., after the policies are applied).

Sriram