IETF Logo Mail Archive

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

"Alvaro Retana (aretana)" <aretana@cisco.com> Fri, 09 December 2016 22:00 UTC

Return-Path: <aretana@cisco.com>
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 47A9D1296AE; Fri, 9 Dec 2016 14:00:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.417
X-Spam-Level:
X-Spam-Status: No, score=-17.417 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, 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
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 GyV8xw2qzjGL; Fri, 9 Dec 2016 14:00:31 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA8CA129584; Fri, 9 Dec 2016 14:00:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25636; q=dns/txt; s=iport; t=1481320830; x=1482530430; h=from:to:cc:subject:date:message-id:mime-version; bh=k1VwhNONkcFlekGLpXdzvqzGflOQyHLr7eVJbedv8r4=; b=TjTSkoIxzPd1gpDeVaYCltwykAcIqeS9Wmx8uf+f/E3H0D6dP6nGFnn8 I0Bo9bCZ7SzgjZUZKrJCbqzg4OfAo3jWdZIQi0ZPfY7JGhS11hmBbPjC+ gz74IuRK0CVxiIjRCsiiWUGiYQPl7zxPDfutC3yZzBP2GDCccO0YCUMEG c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BrAQC8KEtY/4MNJK1dGgEBAQECAQEBAQgBAQEBgnNEAQEBAQEfWoEGB41CrBWCCoYhHIFMPxQBAgEBAQEBAQFiKIRvIwQGTBIBRwMCBDAUEwQBDQUbiFCrCoFsPS+KbwEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GPoF9hngRAYMgLYIwBYY7jkWFawGMcoQugXOEf4lTh2aKMgEfN2I/JA4BAYNggUVyhimBIYENAQEB
X-IronPort-AV: E=Sophos;i="5.33,325,1477958400"; d="scan'208,217";a="357065898"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Dec 2016 22:00:29 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id uB9M0THF007759 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Dec 2016 22:00:29 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 9 Dec 2016 16:00:28 -0600
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Fri, 9 Dec 2016 16:00:28 -0600
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>, "draft-ietf-sidr-bgpsec-protocol@ietf.org" <draft-ietf-sidr-bgpsec-protocol@ietf.org>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>
Thread-Topic: Confederations and Private ASNs (WAS: AD Review of draft-ietf-sidr-bgpsec-protocol-18)
Thread-Index: AQHSUmenE2EHhTbiU0q7IXrD4ZYx2Q==
Date: Fri, 09 Dec 2016 22:00:28 +0000
Message-ID: <7055D209-5BF7-4B5D-A675-356CD2CBFF4D@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1a.0.160910
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.249.235]
Content-Type: multipart/alternative; boundary="_000_7055D2095BF74B5DA675356CD2CBFF4Dciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/Wv9b3sO2Fc8j1_0Q3-HpjblHMWE>
Cc: Matthias Waehlisch <m.waehlisch@fu-berlin.de>, "sidr@ietf.org" <sidr@ietf.org>
Subject: [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: Fri, 09 Dec 2016 22:00:34 -0000

[Changed the Subject to specifically discuss Confederation support, and hopefully get some attention from the WG.]

Sriram:

Hi!  I think the only item left is the Confederations one…and we might be speaking past each other.


Yes, I agree that the collusion problem is one that (as you mentioned below) is out of the scope of BGPsec.  You are right that pCount=0 (as proposed below) doesn’t solve the collusion problem – but it does address the following security guarantee that is currently not met in the Confederations case (from 8.1):

   o  For each AS in the path, a BGPsec speaker authorized by the holder
      of the AS number intentionally chose (in accordance with local
      policy) to propagate the route advertisement to the subsequent AS
      in the path.

In the case of Confederations, it cannot be (currently) verified that all the ASNs in the path intentionally chose to send the update to the next ASN because there is a discontinuity at the border.  For a topology like this: AS1 -> AS2/AS65001 -> AS65002/AS2 -> AS3 (AS2 is the Confederation ID and AS65001 and AS65002 are Members), it can be verified that AS1 intentionally sent the Update to AS2, but there is no explicit indication (even if symbolic: pCount=0) of the intention for AS65001 to “receive” the update, and then be able to send it to AS65002.

I still think that this continuity issue should be addressed; it nothing more just because the intentionality is mentioned as a security guarantee of BGPsec.

Chairs: Please poll the WG or make a decision of whether there is consensus (or not) to not solve this continuity issue (maybe from prior discussions on the list).  If the WG decides not to solve this issue (or if it was already discussed), I’m ok with being in the rough.


Related to the above, is the support for private ASNs --- this topic also came up in the review of draft-ietf-sidr-bgpsec-ops, and the GenArt/SecDir reviews.  There are two related points:


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.  Given that the signing of Updates is mandated, I think that support of draft-ietf-sidr-slurm is necessary; IOW, I think that draft-ietf-sidr-slurm should be a Normative reference.

2.       Private ASNs (as pointed out in the SecDir review) are commonly used for stubs.  This document should include something (I’m thinking in the Ops Section) about the protocol considerations: there must be a ROA from the resource owner for the ISP to properly re-originate the Update, etc..


Thanks!

Alvaro.


On 12/5/16, 1:35 PM, "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov<mailto:kotikalapudi.sriram@nist.gov>> wrote:


Personally, I would have preferred if you actually solved the problem. One solution is to borrow from draft-ietf-sidr-as-migration and forward sign from the Confederation AS (the public number) to the Member-AS with pCount=0.  Note that this operation would take place inside the border Confederation router, so there are no issues with pCount=0 and the full path continuity is preserved.[*] Chairs: I think that this part (whether it is solved or not) should also be bounced by the WG.…



[Sriram-2] Please see discussion at the top of this email. I am afraid, the solution you propose will not work. The first AS in the Confederation can still tunnel the update to the second AS it is colluding with, and the second AS “forward signs from the Confederation AS (the public number) to the Member-AS with pCount=0”. So the problem you originally identified doesn’t go away.

v2.23.0 | Report a Bug | By Email