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

"Alvaro Retana (aretana)" <aretana@cisco.com> Thu, 23 February 2017 21:55 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 AF8341299E3; Thu, 23 Feb 2017 13:55:36 -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 MjfMl0b14Aux; Thu, 23 Feb 2017 13:55:35 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4ACD1298BF; Thu, 23 Feb 2017 13:55:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4730; q=dns/txt; s=iport; t=1487886934; x=1489096534; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kZ85v4Ws8dpGa7bPV+xQKWRlxhfhNTQscVuh5j7WMnM=; b=CWZqVo/6kumGoNRltC+2DQXGkzrNIbnO1S1XhqEhmk9ax96WZHhvhjKA iatGqVKZtYNIVko+Ewfg5M+QXZ3hz2c4EX/hgGvnRkjFf140HCbCYL7Eq Fmzs4KN/P5dNOgnwe6G7v7zKfWQObFnMIxCZpnPEvvLyW5jpfIstFN0Sd Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAgATWa9Y/51dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1BhgQkHg1SKCJFclTSCDR8NhXYCGoMLPxgBAgEBAQEBAQFiKIR?= =?us-ascii?q?wAQEBBAEBIRE6CwwEAgEIEQQBAQMCHwQDAgICJQsUAQgIAgQBDQUUiWEOriOCJ?= =?us-ascii?q?otEAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4VBggWCaodaLoIxBZVphisBhnO?= =?us-ascii?q?LMJERkycBHzhVK1QVPhEBhG+BSHWJCyuBA4ENAQEB?=
X-IronPort-AV: E=Sophos;i="5.35,198,1484006400"; d="scan'208";a="389625902"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2017 21:55:33 +0000
Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v1NLtXiO005685 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Feb 2017 21:55:33 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 23 Feb 2017 15:55:32 -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; Thu, 23 Feb 2017 15:55:32 -0600
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "Jakob Heitz (jheitz)" <jheitz@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+oqQEK9nqF2Wu8wgAEcsQA=
Date: Thu, 23 Feb 2017 21:55:32 +0000
Message-ID: <AF3156BF-6CC9-4DDF-8C7A-4D6EDB9668AB@cisco.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:
user-agent: Microsoft-MacOutlook/f.1f.0.170216
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.6]
Content-Type: text/plain; charset="utf-8"
Content-ID: <6955BA08428BB74AAB6A725D3F12875E@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/AVjv1AWmmhMMTUhfu8n7KDTaj8c>
Cc: "sandy@tislabs.com" <sandy@tislabs.com>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, "sidr@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)
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: Thu, 23 Feb 2017 21:55:36 -0000

[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-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