Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt)
"Jakob Heitz (jheitz)" <jheitz@cisco.com> Fri, 03 March 2017 22:16 UTC
Return-Path: <jheitz@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 5547D12965A; Fri, 3 Mar 2017 14:16:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 24l3Ed7Yx8ss; Fri, 3 Mar 2017 14:16:17 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA4C3129650; Fri, 3 Mar 2017 14:16:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12230; q=dns/txt; s=iport; t=1488579376; x=1489788976; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wIXK0U2rlHdGEouuJvL7BaxwsuYiXjsTrDn7N7EhqdI=; b=iGLpmoW8ay87X3YuebUmyIWzrH0db/vzbB5P+2OS0jQx7A7tQkLClnEd 3FNgs6NZWPELIoscgiAKUl3aB+khLT0phAhA9EBDc8EryWSltkP5BcBjX HA8198C04SKKP9dEiOpQqCXX0ugwCQu8q4xC5WPkTx19NLBXZTmP+drQG c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CVAQDD6rlY/49dJa1eGQEBAQEBAQEBAQEBBwEBAQEBg1FhgQoHg1eKDJFGlTeCDR8NhXYCGoJMPxgBAgEBAQEBAQFiKIRwAQEBAwEBASEROgsFBwQCAQgRBAEBAQICHwQDAgICJQsUAQgIAgQBDQUIDIlfCA6zOoImiwEBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELhUOEb4Rrgm+CXwWVdYY3AYZ1izSCBI8kiEOKdwEfOFgrVhU/hQqBSnaHUyuBA4ENAQEB
X-IronPort-AV: E=Sophos;i="5.35,239,1484006400"; d="scan'208";a="213664223"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Mar 2017 22:15:54 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v23MFsfG030426 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Mar 2017 22:15:54 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 3 Mar 2017 16:15:54 -0600
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Fri, 3 Mar 2017 16:15:54 -0600
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: "Montgomery, Douglas (Fed)" <dougm@nist.gov>, "Alvaro Retana (aretana)" <aretana@cisco.com>, "draft-ietf-sidr-origin-validation-signaling@ietf.org" <draft-ietf-sidr-origin-validation-signaling@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: AQHSbB8KL4goLDO+zUCyR+oqQEK9nqF2Wu8wgAEcsQCADL9tgP//pOHggACCYID//5/aYA==
Date: Fri, 03 Mar 2017 22:15:54 +0000
Message-ID: <5a95316b20e840749135658a9c67444c@XCH-ALN-014.cisco.com>
References: <148414831932.11019.14685466226406323027.idtracker@ietfa.amsl.com> <904eb4e5f3b54f8fb5eeddba482566c6@XCH-ALN-014.cisco.com> <AF3156BF-6CC9-4DDF-8C7A-4D6EDB9668AB@cisco.com> <D4DF2B46.74CF0%dougm@nist.gov> <a95f5dab4456415192d3846d895e2377@XCH-ALN-014.cisco.com> <D4DF4F0B.74D39%dougm@nist.gov>
In-Reply-To: <D4DF4F0B.74D39%dougm@nist.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.90.253]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/X8ZulfToqF7N_pL76m3Loo9bLjc>
Cc: "sidr@ietf.org" <sidr@ietf.org>, "sandy@tislabs.com" <sandy@tislabs.com>
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 22:16:19 -0000
Thanks. This is the part I was looking for: > I would suggest one keep/use the locally computed validation state, > not the signaled state. Jakob. > -----Original Message----- > From: Montgomery, Douglas (Fed) [mailto:dougm@nist.gov] > Sent: Friday, March 03, 2017 1:56 PM > To: Jakob Heitz (jheitz) <jheitz@cisco.com>; Alvaro Retana (aretana) <aretana@cisco.com>; draft-ietf-sidr-origin- > validation-signaling@ietf.org > Cc: sandy@tislabs.com; sidr-chairs@ietf.org; sidr@ietf.org > Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard > (draft-ietf-sidr-origin-validation-signaling-11.txt) > Importance: Low > > > On 3/3/17, 3:24 PM, "Jakob Heitz (jheitz)" <jheitz@cisco.com> wrote: > > >The case is unlikely, but something we need to write code for. > >Without an answer, then the validity will just be set by whichever > >was set last. That would make it indeterminate. > > > >The case is for a single route. There is no suggestion of the validity > >of one route being used to set validity of another. > > By single route, do you mean an update from a specific iBGP peer? Or do > you mean updates from two or more iBGP peers? > > > > >A router may be doing local validation, using rpki-rtr protocol. > >In additiion, it may receive a route with a validation state in > >an extended-community. > > In this case are you saying the router is doing origin validation on iBGP > updates, even though they contain the extended-community? > > If so, I would suggest one keep/use the locally computed validation state, > not the signaled state. > > > > >The question is what to do if one validation method sasys "invalid" > >and the other says "valid". > > > >The situation may arise if the router sending the extended-community > >is using a different validation method, not RPKI. > > It can also happen if all routers are doing RPKI, but there is transient > RPKI state skew between multiple validating caches, local SLURM policies, > etc. > > > > > >Thanks, > >Jakob. > > > >> -----Original Message----- > >> From: Montgomery, Douglas (Fed) [mailto:dougm@nist.gov] > >> Sent: Friday, March 03, 2017 11:36 AM > >> To: Alvaro Retana (aretana) <aretana@cisco.com>; Jakob Heitz (jheitz) > >><jheitz@cisco.com>; draft-ietf-sidr-origin- > >> validation-signaling@ietf.org > >> Cc: sandy@tislabs.com; sidr-chairs@ietf.org; sidr@ietf.org > >> Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation > >>State Extended Community' to Proposed Standard > >> (draft-ietf-sidr-origin-validation-signaling-11.txt) > >> Importance: Low > >> > >> I am not sure I understand the original question/point and/or Alvaro's > >> response. > >> > >> The spec in section 2 says: > >> > >> “...Similarly on the receiving IBGP speakers, the validation state of an > >> IBGP route SHOULD be derived directly from the last octet of the > >>extended > >> community, if present.” > >> > >> > >> That seems like a suggested receive logic … although it is a SHOULD. Of > >> course it is still up to local policy how this validation state effects > >> the decision process. > >> > >> I think it would be a mistake to make some change that suggested that > >>the > >> received validation state on a iBGP update should somehow influence the > >> computed origin validation state of other received updates. In > >>particular > >> influencing the validation state of any locally validated updates. The > >> original question seems to suggest that a received INVALID or VALID > >>might > >> supersede a “NOT_FOUND”. (was that the suggestion?) Such a situation > >> represents an RPKI state skew between the two routers (might just be > >> transitory) but it is impossible to tell if the I/V or the NF represents > >> the more “up to date” result. Also having the origin validation results > >> of a router that is doing OV overwritten by some other router (possibly > >> synced to a different validating cache) will make debugging OV results > >> very difficult. > >> > >> In short, for now, I would not change the spec. With some operational > >> experience we might find some use for similar functionality (I wonder if > >> by NOT_FOUND you meant not validated) but for now, I would not change > >>it. > >> > >> dougm > >> — > >> Doug Montgomery, Mgr Internet & Scalable Systems Research at > >>NIST/ITL/ANTD > >> > >> > >> > >> > >> > >> On 2/23/17, 4:55 PM, "sidr on behalf of Alvaro Retana (aretana)" > >> <sidr-bounces@ietf.org on behalf of aretana@cisco.com> wrote: > >> > >> >[Took the IESG, ietf-announce and rfc-editor lists off.] > >> > > >> >Jakob: > >> > > >> >Hi! > >> > > >> >This document is already in AUTH48. I don’t think we need to make any > >> >changes to the document, but if we do, we need to decide very soon. > >> > > >> >The document doesn’t say anything about what should be done with this > >> >extended community, except to say that “speakers that receive this > >> >validation state can configure local policies allowing it to influence > >> >their decision process.” IOW, there is no expected default processing > >>of > >> >the validation state. > >> > > >> >If the community is received and the router also has validation > >> >information, then I agree that the extended community is not > >>needed…but I > >> >think that action is outside the scope of this document. > >> > > >> >Thanks! > >> > > >> >Alvaro. > >> > > >> > > >> > > >> > > >> >On 2/23/17, 4:26 PM, "iesg on behalf of Jakob Heitz (jheitz)" > >> ><iesg-bounces@ietf.org on behalf of 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? > >> > > >> > I don't see that condition covered in the draft. > >> > I would say to ignore the extended community. > >> > > >> > 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-signa > >>>li > >> >ng/ > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > 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 > >> > > >> > > >> > > >> >_______________________________________________ > >> >sidr mailing list > >> >sidr@ietf.org > >> >https://www.ietf.org/mailman/listinfo/sidr > >
- [sidr] Protocol Action: 'BGP Prefix Origin Valida… The IESG
- Re: [sidr] Protocol Action: 'BGP Prefix Origin Va… Jakob Heitz (jheitz)
- Re: [sidr] Protocol Action: 'BGP Prefix Origin Va… Alvaro Retana (aretana)
- Re: [sidr] Protocol Action: 'BGP Prefix Origin Va… Randy Bush
- Re: [sidr] Protocol Action: 'BGP Prefix Origin Va… Montgomery, Douglas (Fed)
- Re: [sidr] Protocol Action: 'BGP Prefix Origin Va… Jakob Heitz (jheitz)
- Re: [sidr] Protocol Action: 'BGP Prefix Origin Va… Keyur Patel
- Re: [sidr] Protocol Action: 'BGP Prefix Origin Va… Jakob Heitz (jheitz)
- Re: [sidr] Protocol Action: 'BGP Prefix Origin Va… Montgomery, Douglas (Fed)
- Re: [sidr] Protocol Action: 'BGP Prefix Origin Va… Jakob Heitz (jheitz)
- Re: [sidr] Protocol Action: 'BGP Prefix Origin Va… Randy Bush
- Re: [sidr] Protocol Action: 'BGP Prefix Origin Va… Chris Morrow
- Re: [sidr] Protocol Action: 'BGP Prefix Origin Va… Randy Bush
- Re: [sidr] Protocol Action: 'BGP Prefix Origin Va… Chris Morrow
- Re: [sidr] Protocol Action: 'BGP Prefix Origin Va… Jakob Heitz (jheitz)
- Re: [sidr] Protocol Action: 'BGP Prefix Origin Va… Randy Bush
- Re: [sidr] Protocol Action: 'BGP Prefix Origin Va… Chris Morrow
- Re: [sidr] Protocol Action: 'BGP Prefix Origin Va… Jakob Heitz (jheitz)
- Re: [sidr] Protocol Action: 'BGP Prefix Origin Va… Randy Bush
- Re: [sidr] Protocol Action: 'BGP Prefix Origin Va… Keyur Patel
- Re: [sidr] Protocol Action: 'BGP Prefix Origin Va… Jakob Heitz (jheitz)