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

"Montgomery, Douglas (Fed)" <dougm@nist.gov> Fri, 03 March 2017 21:56 UTC

Return-Path: <dougm@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 26B2712963B; Fri, 3 Mar 2017 13:56:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 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, URIBL_BLOCKED=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 2lNoIzFmqQya; Fri, 3 Mar 2017 13:56:19 -0800 (PST)
Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0108.outbound.protection.outlook.com [23.103.200.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55FBA12963A; Fri, 3 Mar 2017 13:56:19 -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=FATYJSMhHw1jExC3PtuP1/qQt5z5fzafBwHXMvBbxNI=; b=MWbrcxms435+YNiKVkYgaXdhUDJAa6UEBkGplU0hnLWc+viXj7n28OdnD0G15mJDDKb+Z2+swqi5HKyzsM0WRlT5j23RJzudzSzrkSMzxzofc7nd026P4o0WVHtt57cXIV4vxyOmbUH3OzYqra7jafqdqDeV18hFM35CjV9Kx7Q=
Received: from BN6PR09MB1426.namprd09.prod.outlook.com (10.173.202.14) by BN6PR09MB1427.namprd09.prod.outlook.com (10.173.202.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Fri, 3 Mar 2017 21:56:17 +0000
Received: from BN6PR09MB1426.namprd09.prod.outlook.com ([10.173.202.14]) by BN6PR09MB1426.namprd09.prod.outlook.com ([10.173.202.14]) with mapi id 15.01.0919.022; Fri, 3 Mar 2017 21:56:17 +0000
From: "Montgomery, Douglas (Fed)" <dougm@nist.gov>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>, "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: AQHSbB8Sc+1j7EQgyk+BThT9XkihhaF3XtSAgAAICQCADBe3AIAAYZEA///FsoA=
Importance: low
X-Priority: 5
Date: Fri, 3 Mar 2017 21:56:17 +0000
Message-ID: <D4DF4F0B.74D39%dougm@nist.gov>
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>
In-Reply-To: <a95f5dab4456415192d3846d895e2377@XCH-ALN-014.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.1.161129
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=nist.gov;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [129.6.140.29]
x-microsoft-exchange-diagnostics: 1; BN6PR09MB1427; 7:N2DwXuHlaMBSv2ER05IxRcr9g66HrD3kxtdaq79FiZr+eK0Wd9sOFZ2eD68pRrYnUie6R3d6lsPYH4upsxPsMb5TOn0C7ou99QzaZkV96Q/9ff3Q28PiH4sAnwJX9HDhq5xTIac+XH/pb7ohjJLC9Uah21r6IDpxmMH5liisw92LRNHY+LuakdGWEW9L0Ln25e5jbktYlx/bcOW+hGOHUWKBjSwSv/KZbzfDG43T/RK3nl02jQhXzisAh1OvVdMjTzCMNHrVWzq33U1VrjGOnA2S01XhGHjmVRB22kRymVQdGDO2VEX5x2Qkj5Si4W66lyp+JiiJAER3zCayVTrnsQ==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39450400003)(39410400002)(39850400002)(39860400002)(13464003)(377454003)(24454002)(2900100001)(230783001)(5660300001)(93886004)(83506001)(92566002)(8936002)(3660700001)(2906002)(6116002)(102836003)(66066001)(4326008)(3280700002)(2501003)(54356999)(81686999)(76176999)(50986999)(81166006)(3846002)(8676002)(6306002)(106116001)(6506006)(2950100002)(6246003)(6436002)(36756003)(6512007)(189998001)(6486002)(99286003)(305945005)(77096006)(7736002)(53546006)(122556002)(25786008)(38730400002)(86362001)(54906002)(229853002)(4001350100001)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR09MB1427; H:BN6PR09MB1426.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
x-ms-office365-filtering-correlation-id: cf3c991a-d123-43e1-3305-08d462801ead
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR09MB1427;
x-microsoft-antispam-prvs: <BN6PR09MB1427B62F254C6AE47D85FAA3DE2B0@BN6PR09MB1427.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(65766998875637)(120809045254105)(95692535739014)(17755550239193);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:BN6PR09MB1427; BCL:0; PCL:0; RULEID:; SRVR:BN6PR09MB1427;
x-forefront-prvs: 0235CBE7D0
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <FC5BB755AA72BE43A50FC1EC05E66F63@namprd09.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2017 21:56:17.3513 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR09MB1427
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/_K12dlmDJBaKArueLr5ti8c1gp4>
Cc: "sidr@ietf.org" <sidr@ietf.org>, "sidr-chairs@ietf.org" <sidr-chairs@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 21:56:22 -0000

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>om>; Jakob Heitz (jheitz)
>><jheitz@cisco.com>isco.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.orgorg; sidr-chairs@ietf.org; The IESG
>> >    > <iesg@ietf.org>rg>; 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
>