Re: [sidr] Confederations and Private ASNs (WAS: AD Review of draft-ietf-sidr-bgpsec-protocol-18)

"Borchert, Oliver (Fed)" <oliver.borchert@nist.gov> Mon, 02 January 2017 15:32 UTC

Return-Path: <oliver.borchert@nist.gov>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3A3120727 for <sidr@ietfa.amsl.com>; Mon, 2 Jan 2017 07:32:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 xAIdyknN4sxQ for <sidr@ietfa.amsl.com>; Mon, 2 Jan 2017 07:32:53 -0800 (PST)
Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0126.outbound.protection.outlook.com [23.103.200.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4962A12965B for <sidr@ietf.org>; Mon, 2 Jan 2017 07:32:53 -0800 (PST)
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=Sa3wD3RiiUzspqX9sQpuoOpeEUPlWFxK/nU7FXT9T40=; b=LfmKVRIl07SB+c0F3IcvxWFv6R4OEBO+CEZLqRFbmjFROdDj+kH8ruW8zKdqkCuaY64A/yPBFesU/aJRfJid6X0fFDxtDXpbjJ/zFPyrX2Ub+8DJ6zt4/EaPSxvgVU3cxHFo9DqTmsr6BLnh2IpdLy/RWZ+Gfd98TmF9V44eVPc=
Received: from BL2PR09MB0996.namprd09.prod.outlook.com (10.167.102.15) by CY1PR09MB0443.namprd09.prod.outlook.com (10.160.150.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Mon, 2 Jan 2017 15:32:50 +0000
Received: from BL2PR09MB0996.namprd09.prod.outlook.com ([10.167.102.15]) by BL2PR09MB0996.namprd09.prod.outlook.com ([10.167.102.15]) with mapi id 15.01.0817.009; Mon, 2 Jan 2017 15:32:49 +0000
From: "Borchert, Oliver (Fed)" <oliver.borchert@nist.gov>
To: Randy Bush <randy@psg.com>, "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
Thread-Topic: [sidr] Confederations and Private ASNs (WAS: AD Review of draft-ietf-sidr-bgpsec-protocol-18)
Thread-Index: AQHSUmenE2EHhTbiU0q7IXrD4ZYx2aEfNZ3QgAB6v4CABXIAAA==
Date: Mon, 02 Jan 2017 15:32:48 +0000
Message-ID: <C87ADFEE-F441-45C6-A059-573BA48ACEDE@nist.gov>
References: <7055D209-5BF7-4B5D-A675-356CD2CBFF4D@cisco.com> <CY1PR09MB0444EAC40C875F576A451F8F846B0@CY1PR09MB0444.namprd09.prod.outlook.com> <m2zije5ngk.wl-randy@psg.com>
In-Reply-To: <m2zije5ngk.wl-randy@psg.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1d.0.161209
authentication-results: spf=none (sender IP is ) smtp.mailfrom=oliver.borchert@nist.gov;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [108.56.241.51]
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0443; 7:7ddYX8RRNpZLHKFMXslSKz7X44npLmszGAS6nwhAd/sC+nxfAXOEkL/xmuiD0miMkv1Hh5YXoa0o7DAvCwC8JEMoHKSx9pDoWZFynxXCkm1XXeW2rzzumzYMGXkB1ziI5DP4y8Tjko0y1H8t5EvHo/GEmoWX4B6fgX+D2rzQndzCutsXFGi4lwXKkcrMal5oKSRwslYsFw6H/iZ9/MAhdXPJ2tvnyONG4qV1ZcET6AKMHkpK7RtIpjNix+Lp2TQAFgktbRUYdSE+VWsCMLLfFiWWfz2EUTZAjcqB8Lqc0Gsh/hOsPopq5IH4H7l6WgXJy9h+gR5a4VYgTzpxuNMaawOeGXaTi+XebggnTC/UXjC8F3/yeO0U6bjbEqv/egNu0QzNyHYhZJ9FsFANpbANBlMZ3bfuNDTcaUkHZL/Q7JWcTsUWf6/6bz/+dUmmEFUsMJkGzRD0X0Iqyk5IbEJAWw==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39410400002)(39450400003)(39850400002)(377454003)(199003)(189002)(24454002)(76176999)(6506006)(230783001)(25786008)(54356999)(82746002)(83506001)(36756003)(2900100001)(6436002)(38730400001)(5001770100001)(83716003)(66066001)(81166006)(99286003)(229853002)(68736007)(33656002)(81156014)(101416001)(106356001)(2950100002)(8676002)(86362001)(77096006)(97736004)(102836003)(50986999)(6512006)(6486002)(7736002)(122556002)(3660700001)(2906002)(189998001)(106116001)(3280700002)(5660300001)(105586002)(8936002)(4326007)(3846002)(6862003)(6636002)(4001350100001)(305945005)(92566002)(6116002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0443; H:BL2PR09MB0996.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
x-ms-office365-filtering-correlation-id: ad8b376e-3eaf-43f4-20ed-08d433249bbb
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0443;
x-microsoft-antispam-prvs: <CY1PR09MB0443AC638F2A400D9299AA3E986F0@CY1PR09MB0443.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123558021)(20161123560025)(6072148); SRVR:CY1PR09MB0443; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0443;
x-forefront-prvs: 017589626D
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <24267A3314DF11498AD0761CC600C81A@namprd09.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2017 15:32:48.9162 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0443
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/fguWWcaaIzIkIlYIObrH0DfoF7c>
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] Confederations and Private ASNs (WAS: AD Review of draft-ietf-sidr-bgpsec-protocol-18)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Jan 2017 15:32:55 -0000

See my comments inline

On 12/29/16, 6:23 PM, "sidr on behalf of Randy Bush" <sidr-bounces@ietf.org on behalf of randy@psg.com> wrote:

    >>> 1. It is common to use private ASNs in Confederations, 
    >> but the global RPKI can’t support that.  draft-ietf-sidr-slurm seems
    >> to address the issue of local management of private resources in the
    >> RPKI.  …
    
    >the issue is not how the confed AS validates ROAs of the private ASs in
    >the confed.  that is trivial and supported by existing software.  my
    >questions revolve around path processing.


I believe the answer to your question is found in section 7, paragraph #8 and following. 
There I see explanation on how to process the path using private AS numbers, etc.

    
    >4.3 confuses me by using 'private' ambiguously.  i have tried to read
    >that section yet again and drowned in the mass of words.  perhaps more
    >coffee will help; but i am not optimistic.  i pity the implementors. 
    >
    >randy    

Revisiting Section 4.3, I made the following observations:
In my opinion the second Paragraph explains clearly the process of the ingress BGPSec 
router at the confederation boundary. I believe the process described of adding a 
signature with pCount=0 will resolve the issue that Alvaro observed.

Said that, I feel that the explanations in paragraphs #3 and #4 are not very helpful. 
There I do agree with Randy's "mass of words" comment. I suggest to either shorten 
them or completely remove them. These two paragraphs are not needed, in contrary 
they might add unnecessary confusion.

When removed the following current paragraphs 5 and following do explain clearly the
process in the intermediate AS-members and the egress BGPSec router of the 
confederation.

In short I think paragraphs #3 and #4 disrupt the flow and are not so helpful,
so I propose to remove them.

To avoid unnecessary confusion with the ambiguity of the word private, I would change 
the wording of “the (private) Member-AS Number” to “the Member-AS Number” by 
removing the wording of “(private)” within parenthesis. 
This leaves the usage of private only for the signing parties private key which I think 
is well understood.

Oliver