Re: [Sidrops] draft-sidrops-rpkimaxlen

"Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov> Sat, 23 February 2019 22:04 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 C15A4130DDA; Sat, 23 Feb 2019 14:04:17 -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, 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 b0YLHXu9gpBA; Sat, 23 Feb 2019 14:04:14 -0800 (PST)
Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-eopbgr840102.outbound.protection.outlook.com [40.107.84.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 8C8A0130F7B; Sat, 23 Feb 2019 14:04:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=emwGyazwhSmkLBoj6Y/VtdPRbzTuvXNxloOJZ3/0MOU=; b=Qt6UnMjKUMaGGOCnPT8HPtcL8TY4TZ94QyOMEcCg0yidJlUNkq/3AZVPst+hUwDpq75co+xoUnaFMucbzQn3rL4X0vlf6sX5NFLnG+PSnK6WVlTytVl9XQoN924f/16dDHti1dUwJx9/Jc4h2j43lL7wm0TpQTGIsCulPZ6olTU=
Received: from SN6PR0901MB2366.namprd09.prod.outlook.com (52.132.115.159) by SN6PR0901MB2368.namprd09.prod.outlook.com (52.132.116.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.16; Sat, 23 Feb 2019 22:04:07 +0000
Received: from SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::5c3a:f8a5:80dd:2d85]) by SN6PR0901MB2366.namprd09.prod.outlook.com ([fe80::5c3a:f8a5:80dd:2d85%5]) with mapi id 15.20.1643.016; Sat, 23 Feb 2019 22:04:07 +0000
From: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
To: Matthias Waehlisch <m.waehlisch@fu-berlin.de>
CC: "sidrops@ietf.org" <sidrops@ietf.org>, "draft-ietf-sidrops-rpkimaxlen@ietf.org" <draft-ietf-sidrops-rpkimaxlen@ietf.org>
Thread-Topic: [Sidrops] draft-sidrops-rpkimaxlen
Thread-Index: AQHUy8AmUSoU77RRv0K+rD/l/1dVIg==
Date: Sat, 23 Feb 2019 22:04:07 +0000
Message-ID: <SN6PR0901MB236677B37676FFB11A22B14D84780@SN6PR0901MB2366.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.223.49]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c1bd40d5-541d-4469-54a2-08d699dad528
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:SN6PR0901MB2368;
x-ms-traffictypediagnostic: SN6PR0901MB2368:
x-ms-exchange-purlcount: 3
x-microsoft-exchange-diagnostics: =?iso-8859-1?Q?1; SN6PR0901MB2368; 23:MSCPnjwSW7F+DaFJY/N1OFXDHS3OitE0RzD6c?= =?iso-8859-1?Q?vwFCYEqat3z5fnGr0tfdXy/OL8dRPF1CTPVm4QfhDjk7H0O1xrhnNAf8ui?= =?iso-8859-1?Q?skDBZR1J7u87/wvVI2GB/hocHY+LnikUyT+DpSfdDC15NJcb3ZLceK7i07?= =?iso-8859-1?Q?+KHVW8B1jJPG6904rkty+MCVKw43uKoexukFF9EdoRTsiZZVqfKcmPCWgF?= =?iso-8859-1?Q?4Eh5bqb5DRXDmfn8cQLd1PFOiE8JeWMZ6HpFOTisJK/3eYyMfeKtYCfFzo?= =?iso-8859-1?Q?aEA80fA59brBK5q2b1gGMN+7HMMvYULMPDQQppSXJX2Ow56vGQb4CP9UgK?= =?iso-8859-1?Q?hRv5M98xumAZMKU7t1lVn82n99uhBtaDAc8jYqts3tOt6O43NFi4xZPKtY?= =?iso-8859-1?Q?7L8qLE8aROO0hfdK+zza09XizbFRHdyn7kfj93/6dwYngKg4ubRMjNClot?= =?iso-8859-1?Q?FmSuK4Rlm7ad8I62fB7YwdLWOUjssHvJJ3m4rpcioDyW+Gqs0NGB5dHbmP?= =?iso-8859-1?Q?V4ke4LpaP4OPR+zZpvh3OeM+wnhfBKPbHdgprEmHz0qvLkimJ1HATxZfKJ?= =?iso-8859-1?Q?JHF7NkLJ4awDK6rAc7aggGEqXjTiWBRbAQ3WHOj0az83dw0kvC2KZLnl4Y?= =?iso-8859-1?Q?mJzZXLSZSqdSjcxHnTONAyhKfHZ4yh0lkrp63LS/Og9xIVbJ4/IUedJBDB?= =?iso-8859-1?Q?hPypr85WDEPDpbJGbF/C9Ne0iy7fOD7DF+a5SIlA3Ac9CTQRi8vBA3pIDK?= =?iso-8859-1?Q?jxdvfoeTsavG4KKJkHIu2ycNnqKUt9MuHnnxrtd1qMlhTGvio2FfcIh+ox?= =?iso-8859-1?Q?1Fx7XDl0YgG1wY/Ahp6bR8N1sW25HG2pVZ6OiJiZ0AIcR3SeQHRazM0A10?= =?iso-8859-1?Q?TUS2hsYlc/aXhQDVQwRNw1hIIIB/s+gmujXJhixo3foew98Mh3sKRrl6bM?= =?iso-8859-1?Q?lcXyBd1vAWV+th823YbrUSoWPnltfW38C6ctQT/YSqn0Q2HYzBTd5pzmdX?= =?iso-8859-1?Q?X2jUSZLXhy9GnA/YMLAmayHQrdRVw8jftDCxCr0Atr2k+c1itKBXQg+R7M?= =?iso-8859-1?Q?TUriV8tvQV/fcTmAqsQ2kLtELcn/K4OIDjdOTKGEGVsBb29H4NIvjMPPSw?= =?iso-8859-1?Q?oZA1YCwjwTn03KeAIJGR004jYXqL/yyuSZWmTmlUu5lTbKbuOgLnxN9pQD?= =?iso-8859-1?Q?jCs+lv2Wrm9NYCzGV4Cuqb1cziqEmCATbBBGUHBR+2p9MTCiTkNRuN7WwL?= =?iso-8859-1?Q?Lh+5tXSw/9Lce8dYye0sL/dcXqemLTt1JBJ8UWsOw=3D=3D?=
x-microsoft-antispam-prvs: <SN6PR0901MB2368E929ED824DD21000BA9784780@SN6PR0901MB2368.namprd09.prod.outlook.com>
x-forefront-prvs: 0957AD37A0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(366004)(376002)(346002)(39850400004)(43544003)(189003)(199004)(476003)(54906003)(81156014)(86362001)(55016002)(6436002)(68736007)(8676002)(6116002)(106356001)(486006)(8936002)(186003)(7736002)(105586002)(3846002)(966005)(478600001)(5660300002)(81166006)(26005)(14454004)(305945005)(4326008)(7696005)(74316002)(256004)(14444005)(97736004)(25786009)(33656002)(52536013)(99286004)(316002)(6916009)(2906002)(71200400001)(71190400001)(6506007)(9686003)(66066001)(102836004)(6246003)(53936002)(229853002)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR0901MB2368; H:SN6PR0901MB2366.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: uUZ9YLPzh5MMFRU0e0M5Kx4YnDc17xMIogqR4hl2ITyy5hy87z/4KcJ5qX65iapAsXjkjfkr7SaQW9vNB4nGGh/MRev+wtDJw3yFo/O+/1s3UDGhJlQwIrY0zUhkZCczZGu6nPfyTC47+NA/WL+dFT77fQP3FiDY/rfXCzBVGSRiB3atuMyznbyDxmnfaUyxgZ7Q0sa2AApOlQHqo1mi5k7dAvDHxvEWeq9SH1ICKq/9i1H5GUTHqdZWrKPBZkovoJRUDxgs+LSvobAI7EWtgvls8qBqCMW7eeDBBM3pfrfVy1ns8wLVznG9pkBAb0DGVv4stKPl1NaOz9SmCbL7RAVzp1T87698i8Q/pZFtmBtomjqHPk49QwKuNpHossBkFjH2xGZagRjJ75PHEwZzv4EHmbWsH/MOZCBnygleeZU=
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: c1bd40d5-541d-4469-54a2-08d699dad528
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2019 22:04:07.6783 (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-Transport-CrossTenantHeadersStamped: SN6PR0901MB2368
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/4HoNYkTYWBAV6azuqQz0gscTYUs>
Subject: Re: [Sidrops] draft-sidrops-rpkimaxlen
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: Sat, 23 Feb 2019 22:04:18 -0000

Hi Matthias,

>I read the (expired) draft draft-sidrops-rpkimaxlen.

It appears that a fork in the draft stream occurred inadvertently 
sometime ago when Job tried to upload a new version. 
You were looking at the "expired" branch. 
The draft is active:
https://tools.ietf.org/html/draft-ietf-sidrops-rpkimaxlen-01   

>The problem analysis in the draft is misleading.
>The problem is not the usage of the max length field. Even without a
>max length field, a "forged-origin subprefix hijack" may occur easily. 
>For example, a minimal, more specific ROA has been created, and the 
>prefix is currently not announced by the origin AS configured in the ROA.

IMO, the spirit and intention of the document is in complete alignment 
with what you are trying to covey. It is the *misuse* of maxlength that 
the draft cautions about. Adding the following wording (with some 
further refinement) in the document will help clarify:

A minimal ROA is one which includes prefixes that are currently 
announced or are intended to be announced. Use of maxlength 
can be avoided or it should be used judiciously so that 
more specific prefixes that are not intended to be announced 
are not covered by the ROA. The idea is to minimize the attack
surface corresponding to forged-origin subprefix hijacking.     

>The draft implicitly suggests: "Only create ROAs for prefixes that are 
>currently announced." I'm not sure whether the WG has consensus about 
>that.

This was not the intent in the draft. A better definition of minimal ROA as
outlined above will take care of the misunderstanding. 
The draft did recognize that the IP prefixes planned to be announced 
in the future or intermittently (when needed) may be included in the ROA.
Please see the following paragraph from Section 5.1:  

   "In this case, the ROA SHOULD include (1) the set of IP prefixes that
   are always originated in BGP, and (2) the set IP prefixes that are
   sometimes, but not always, originated in BGP.  The ROA SHOULD NOT
   include any IP prefixes that the operator knows will not be
   originated in BGP."

There is a use case described after that involving DDoS mitigation.

>The draft is expired. I suggest to leave it expired because it leads 
>to incorrect conclusions, see for example 
>https://github.com/DECIX/RPKI/wiki/RPKI-deployment-options 

I carefully went through the link you've provided. Nice work!
I do not see any inconsistency between your approach with ROAs 
and what is in the draft, especially with the better definition of ROA as
stated above (IMO). Please let us know if you still see it differently.
In fact, there is a similarity between your Blackhole use case
and the DDoS mitigation use case in the draft (except that 
the latter doesn't involve prefixes more specific than /24 IPv4  or /48 IPv6).

DDoS mitigation providers' needs are discussed in Section 5.1 
and network operators seem to have found that discussion and 
related recommendations quite useful. Please see this thread: 

https://lists.arin.net/pipermail/arin-tech-discuss/2018-August/000723.html   

It should be noted that the document is aimed to be a BCP, not standards track.

Thanks for your inputs.

Regards,
Sriram