IETF Logo Mail Archive

Re: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-02.txt

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Tue, 25 July 2017 17:27 UTC

Return-Path: <jheitz@cisco.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E652B131E5E; Tue, 25 Jul 2017 10:27:05 -0700 (PDT)
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 K9O674pfqN43; Tue, 25 Jul 2017 10:27:04 -0700 (PDT)
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 93FDD131E64; Tue, 25 Jul 2017 10:27:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3100; q=dns/txt; s=iport; t=1501003623; x=1502213223; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Hiov2uHi7aQ3klJyNiDhgFluF4zsZdZElDeZs3EloaE=; b=e05ws8KVD+tqwcV2+d2rrKOqin3pCO/NHm31SsSotsZWTWDxZxK6F/Ez ImbHTy6fFhKSBzBDN4zSw03AVmlnYIvXL2muY5Xl7q+Bx7FM/ngqiZjGP fdlmVEXbMj05zlG+vdPC0BnFv53y5QlhoL0Ucb3UJY8eN0cDvLpm0WVTs U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CaAABafndZ/5BdJa1dGQEBAQEBAQEBAQEBBwEBAQEBg1pkgRQHjgWRaJYGghIhC4RMTwIagx0/GAECAQEBAQEBAWsohRgBAQEBAwEBIRE6CwwEAgEIEQQBAQECAiMDAgICJQsUAQgIAgQBDQUIDAeKFBCxR4Imi0kBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELgh2DTYFhgySETRCDKYJhBZ9XApQUkkKVaAEfOIEKdxVJhxl2hnYBJAeBBYEOAQEB
X-IronPort-AV: E=Sophos;i="5.40,411,1496102400"; d="scan'208";a="461034499"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jul 2017 17:27:02 +0000
Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v6PHR2Ip022445 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Jul 2017 17:27:02 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 25 Jul 2017 12:27:01 -0500
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; Tue, 25 Jul 2017 12:27:01 -0500
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Job Snijders <job@instituut.net>, Aris Lambrianidis <aristidis.lambrianidis@ams-ix.net>
CC: "sidrops@ietf.org" <sidrops@ietf.org>, "draft-ietf-sidrops-route-server-rpki-light@ietf.org" <draft-ietf-sidrops-route-server-rpki-light@ietf.org>, Nick Hilliard <nick@foobar.org>
Thread-Topic: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-02.txt
Thread-Index: AQHSst7I9CejtHqlcUC81n91Ri0w36HAq9eAgJhDYwCABkW+gIAGYIMAgAANbAD//8r1YA==
Date: Tue, 25 Jul 2017 17:27:01 +0000
Message-ID: <1fb673f586c74af8992c9b5c6a19333d@XCH-ALN-014.cisco.com>
References: <149192729348.15702.14003842869826829117@ietfa.amsl.com> <8EB8DB53-793E-4269-8CF4-6BAB1D2B76B6@de-cix.net> <B3BC1C5C-27AE-4809-82B6-297D090CEF0C@ams-ix.net> <5971FE7B.6060607@foobar.org> <F1D60787-5C00-46EF-BADE-8E68ECDEB506@ams-ix.net> <20170725152640.o2kqovryesai3ysh@hanna.meerval.net>
In-Reply-To: <20170725152640.o2kqovryesai3ysh@hanna.meerval.net>
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.154.160.157]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/htUKPdPmLD9z5E3wJt3Jqb4uQcs>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-02.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Jul 2017 17:27:06 -0000

You accept the community only from those you trust. Internal or external.
Fpr example, if you know that the neighbor is performing validation to your standard.
There is an approximate correlation between trust boundary and AS boundary.
If you trust someone in another AS, then they should be able to send you the commmunity.

Thanks,
Jakob.


> -----Original Message-----
> From: Sidrops [mailto:sidrops-bounces@ietf.org] On Behalf Of Job Snijders
> Sent: Tuesday, July 25, 2017 8:27 AM
> To: Aris Lambrianidis <aristidis.lambrianidis@ams-ix.net>
> Cc: sidrops@ietf.org; draft-ietf-sidrops-route-server-rpki-light@ietf.org; Nick Hilliard <nick@foobar.org>
> Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-02.txt
> 
> Hi,
> 
> On Tue, Jul 25, 2017 at 04:38:38PM +0200, Aris Lambrianidis wrote:
> > We’re working on an updated draft to elaborate further on the valid
> > path hiding concerns you raised, as well as describing a new
> > transitive extended BGP community attribute, (instead of reusing the
> > one described in RFC8097), based on Job Snijders’ offline comments.
> 
> I elaborated that using a non-transitive extended community to cross
> EBGP boundaries (in my opinion) is a mis-use of the community transivity
> type. I know of a number of BGP implementations which will not send or
> accept non-transitive extended communities across EBGP borders.
> 
> I am not sure whether a transitive extended community is the way to go
> either. A transitive extended community will allow an adversary to
> tunnel through networks which don't recognize the semantics of the "BGP
> Prefix Origin Validation State Transitive Extended Community" and
> possibly negatively impact such networks. This is the trouble with
> communities: the granularity available to limit scope and distributino
> is very coarse.
> 
> I'm not sure there is a good solution here. Any adversy will tag the
> malicious announcement as "this is perfectly valid" and hope the 'valid'
> community helps mitigate 'rpki light' barriers.
> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops

v2.23.0 | Report a Bug | By Email