IETF Logo Mail Archive

Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11

"Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov> Wed, 29 April 2015 18:46 UTC

Return-Path: <kotikalapudi.sriram@nist.gov>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BA91A8903; Wed, 29 Apr 2015 11:46:37 -0700 (PDT)
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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 6J3DbXKOMgJG; Wed, 29 Apr 2015 11:46:35 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0774.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:774]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B50C81A88BE; Wed, 29 Apr 2015 11:46:34 -0700 (PDT)
Received: from CY1PR09MB0793.namprd09.prod.outlook.com (25.163.43.143) by CY1PR09MB0795.namprd09.prod.outlook.com (25.163.43.145) with Microsoft SMTP Server (TLS) id 15.1.148.16; Wed, 29 Apr 2015 18:46:18 +0000
Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([25.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([25.163.43.143]) with mapi id 15.01.0148.008; Wed, 29 Apr 2015 18:46:18 +0000
From: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
To: Iljitsch van Beijnum <iljitsch@muada.com>, David Mandelberg <david@mandelberg.org>
Thread-Topic: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11
Thread-Index: AQHQgeES7U91mgLFt0G5eeS9M69BR51izU6AgAAyNACAAAewgIABRAfg
Date: Wed, 29 Apr 2015 18:46:18 +0000
Message-ID: <CY1PR09MB079302CC52C7791F3C0C512984D70@CY1PR09MB0793.namprd09.prod.outlook.com>
References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <ECDAD8F2-1C27-4494-887C-59280D7FF973@muada.com> <EF4348D391D0334996EE9681630C83F02D173BEB@xmb-rcd-x02.cisco.com> <B1EDF7B6-1E42-440E-BD3F-29723AD7E4A4@muada.com> <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.com>
In-Reply-To: <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: muada.com; dkim=none (message not signed) header.d=none;
x-originating-ip: [129.6.140.100]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0795;
x-microsoft-antispam-prvs: <CY1PR09MB079517F5C61A50B693F5875884D70@CY1PR09MB0795.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0795; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0795;
x-forefront-prvs: 05610E64EE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(2656002)(99286002)(62966003)(86362001)(77156002)(230783001)(5001770100001)(54356999)(76576001)(93886004)(5001960100002)(76176999)(50986999)(46102003)(92566002)(33656002)(66066001)(2950100001)(2900100001)(102836002)(40100003)(106116001)(87936001)(5001920100001)(122556002)(74316001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0795; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2015 18:46:18.1300 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0795
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/c21mjwT8epKE7LZ1nNR2h0joNSQ>
Cc: "idr@ietf.org" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Wed, 29 Apr 2015 18:46:38 -0000

Hi Iljitsch,

>But unless I missed something, the BGPsec drafts don't even talk about the unknown state: 
>"The validation procedure results in one of two states: 'Valid' and 'Not Valid'."
>I don't see any reasonable deployment scenario with only valid and invalid. I think this needs to be addressed in a BGPsec document.

The validation in the BGPsec draft is only about the AS path signatures in signed updates.
It is talking about the validity of the Secure_Path.   
If all the signatures in a Signature_Block are valid, then the Signature_Block (and hence Secure_Path) is 'Valid';
Else, the Signature_Block is 'Not Valid'.
If there are two Signature_Blocks (e.g. when two different algorithms are in use) in an update, 
then at least one of them must be 'Valid' in order for the Secure_Path to be valid.

Separately, prefix-origin validation has three possible outcomes as you have observed already.
That is the topic of RFC 6483 (Informational) and RFC 6811 (Standards Track).

Sriram

v2.23.0 | Report a Bug | By Email