Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt)

Keyur Patel <keyur@arrcus.com> Fri, 03 March 2017 20:43 UTC

Return-Path: <keyur@arrcus.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 B9EBA129602; Fri, 3 Mar 2017 12:43:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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=netorgft1331857.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 yzSxX93o88if; Fri, 3 Mar 2017 12:43:32 -0800 (PST)
Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3314129528; Fri, 3 Mar 2017 12:43:31 -0800 (PST)
Received: from pure.maildistiller.com (unknown [10.110.50.29]) by dispatch1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTP id 75AF860064; Fri, 3 Mar 2017 20:43:31 +0000 (UTC)
X-Virus-Scanned: Proofpoint Essentials engine
Received: from mx9-us1.ppe-hosted.com (unknown [10.110.49.251]) by pure.maildistiller.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 3A9A960049; Fri, 3 Mar 2017 20:43:31 +0000 (UTC)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0116.outbound.protection.outlook.com [207.46.163.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx9-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 93F9818007F; Fri, 3 Mar 2017 20:43:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector1-arrcus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=S3lUjlMBe93ZrvYOYrL/PGGdqHvUi8yz7llfSyHWkQ4=; b=mKvlb9aVJo4l6hBKydQZO/fSEOiDggdX+QC8REWyGnghRWMyMYWQjSDjldpn7W2YvTU0NWjNkZi9Vqy26hY45ihQwO079XJJ/IoAk2EWwuQlqrvQ9CpTz7urPN66ydrO45Gs2AgvSGbyf/3tFBA/aS1sqTREPeXE212FrsNv3KM=
Received: from BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) by BY2PR18MB0262.namprd18.prod.outlook.com (10.163.72.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Fri, 3 Mar 2017 20:43:18 +0000
Received: from BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) by BY2PR18MB0262.namprd18.prod.outlook.com ([10.163.72.152]) with mapi id 15.01.0933.020; Fri, 3 Mar 2017 20:43:18 +0000
From: Keyur Patel <keyur@arrcus.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>, The IESG <iesg-secretary@ietf.org>, IETF-Announce <ietf-announce@ietf.org>
Thread-Topic: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt)
Thread-Index: AQHSbB7tzlS1UVmWk0KSI6cn7Yzvt6F3XtWAgAwAYgA=
Date: Fri, 03 Mar 2017 20:43:18 +0000
Message-ID: <EE5B24BB-386F-47E0-9F0C-3E6E48FBDFF1@arrcus.com>
References: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com>
In-Reply-To: <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=arrcus.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [96.68.143.133]
x-ms-office365-filtering-correlation-id: 17115c7b-4396-4ddd-2af2-08d46275ecab
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BY2PR18MB0262;
x-microsoft-exchange-diagnostics: 1; BY2PR18MB0262; 7:CSa0GQIWN17ICyq085FGTL3ScmowRwnjr5feplOWa8JAjXFtCPfyXxHI4Ync6df5dNTOGhjXUKC+L9SRisRDctF5BCwFZFPpDR/9fQEpDBnqCrAPpHG3oe2qwgJvlU2qidxl6/swF+I3BnZ3kkxOaIcsEbarKBjXRlvjy/HNYWbpm4WpxtY46eKAVpTbBg3rXf5z/5KoEJ14mrSjRBYeRp4sm47u7X3fhOFgOHx3oyLooPoqQyeMD7XEYbjGCiVp/7l0xeT+P+O83EBaJGQLLV0GZEQ2elwocGFoGxDrd9GYZU6cm9T88pz85sU0RLsZ9YA/iCAGPWvzOCqZjEKhZQ==
x-microsoft-antispam-prvs: <BY2PR18MB026210CC50DC248277395422C12B0@BY2PR18MB0262.namprd18.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(120809045254105)(95692535739014)(17755550239193);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(2016111802025)(6072148)(6043046); SRVR:BY2PR18MB0262; BCL:0; PCL:0; RULEID:; SRVR:BY2PR18MB0262;
x-forefront-prvs: 0235CBE7D0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(39410400002)(39830400002)(24454002)(377454003)(13464003)(305945005)(8676002)(33656002)(7736002)(81166006)(53546006)(83716003)(8936002)(5660300001)(122556002)(2950100002)(4326008)(230783001)(6116002)(102836003)(106116001)(3846002)(6436002)(82746002)(6486002)(77096006)(36756003)(66066001)(3660700001)(229853002)(53936002)(2900100001)(54356999)(76176999)(6246003)(6512007)(86362001)(3280700002)(99286003)(54906002)(6306002)(2906002)(189998001)(38730400002)(6506006)(25786008)(92566002)(50986999)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR18MB0262; H:BY2PR18MB0262.namprd18.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <37DF7766BFF34C4A9BFD617AF7C430AD@namprd18.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: arrcus.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2017 20:43:18.5387 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR18MB0262
X-MDID: 1488573811-Qp54ImIgU9Ed
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/UESECCtnBHG0a5qkLeQrWpH-tyQ>
Cc: "draft-ietf-sidr-origin-validation-signaling@ietf.org" <draft-ietf-sidr-origin-validation-signaling@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, The IESG <iesg@ietf.org>, "sandy@tislabs.com" <sandy@tislabs.com>, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>
Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt)
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, 03 Mar 2017 20:43:41 -0000

Jacob,

Apologies for the delayed response. Comments #Keyur

On 2/23/17, 1:26 PM, "Jakob Heitz (jheitz)" <jheitz@cisco.com> wrote:

    What happens if a BGP speaker validates a route in its own RPKI database
    and finds it to be either Valid or Invalid (not NotFound) and also receives
    the extended community that specifies a different validation state?
    
#Keyur: That pretty much means that ibgp speakers has out of sync rpki data. This could very well happen if the ibgp speakers have different refresh intervals for polling the rpki data (or some error has occurred that has resulted into a stale state).

    I don't see that condition covered in the draft.
    I would say to ignore the extended community.
    
#Keyur: I am not sure if we need to add any text? Extended community maps to a policy on a n inbound side. Policy would dictate how you would want to use the community. Implementations could always log any conflicting rpki state they encounter?

Regards,
Keyur

    Thanks,
    Jakob.
    
    > -----Original Message-----
    > From: sidr [mailto:sidr-bounces@ietf.org] On Behalf Of The IESG
    > Sent: Wednesday, January 11, 2017 7:25 AM
    > To: IETF-Announce <ietf-announce@ietf.org>
    > Cc: draft-ietf-sidr-origin-validation-signaling@ietf.org; sidr@ietf.org; sidr-chairs@ietf.org; The IESG
    > <iesg@ietf.org>; sandy@tislabs.com; rfc-editor@rfc-editor.org
    > Subject: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard
    > (draft-ietf-sidr-origin-validation-signaling-11.txt)
    > 
    > The IESG has approved the following document:
    > - 'BGP Prefix Origin Validation State Extended Community'
    >   (draft-ietf-sidr-origin-validation-signaling-11.txt) as Proposed
    > Standard
    > 
    > This document is the product of the Secure Inter-Domain Routing Working
    > Group.
    > 
    > The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah
    > Brungard.
    > 
    > A URL of this Internet Draft is:
    > https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-validation-signaling/
    > 
    > 
    > 
    > 
    > 
    > Technical Summary
    > 
    >    This document defines a new BGP opaque extended community to carry
    >    the origination AS validation state inside an autonomous system.
    >    IBGP speakers that receive this validation state can configure local
    >    policies allowing it to influence their decision process.
    > 
    > Working Group Summary
    > 
    >   This document has had consistent interest from the working group.
    >   Because it defines a new BGP community, it was reviewed by the idr
    >   working group as well.
    > 
    > Document Quality
    > 
    >   The document has been implemented by major router vendors.
    >   It is known to be in use in two large IXPs, AMS-IX and DE-CIX.
    > 
    > Personnel
    > 
    >   Document Shepherd: Sandra Murphy
    >   Responsible Area Director: Alvaro Retana
    > 
    > _______________________________________________
    > sidr mailing list
    > sidr@ietf.org
    > https://www.ietf.org/mailman/listinfo/sidr