Re: [sidr] AD Review of sidr-origin-validation-signaling-09

Randy Bush <randy@psg.com> Wed, 30 November 2016 01:40 UTC

Return-Path: <randy@psg.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 29A00129D31 for <sidr@ietfa.amsl.com>; Tue, 29 Nov 2016 17:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.398
X-Spam-Level:
X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 fF1hkTGO3h9l for <sidr@ietfa.amsl.com>; Tue, 29 Nov 2016 17:40:48 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 37178129D23 for <sidr@ietf.org>; Tue, 29 Nov 2016 17:40:42 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from <randy@psg.com>) id 1cBtt0-0002Pu-Ou; Wed, 30 Nov 2016 01:40:39 +0000
Date: Tue, 29 Nov 2016 17:40:37 -0800
Message-ID: <m2fum9iw2y.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: "John G. Scudder" <jgs@juniper.net>
In-Reply-To: <917E9000-8F1F-4E4F-BDEC-767E3510A71A@juniper.net>
References: <88A45E79-880B-4F82-9FAA-80C05627A49F@cisco.com> <917E9000-8F1F-4E4F-BDEC-767E3510A71A@juniper.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/R8ChEtyzKclDRA2nGRp-2sXlA7M>
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] AD Review of sidr-origin-validation-signaling-09
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: Wed, 30 Nov 2016 01:40:50 -0000

> > C2. [Major] Security Considerations.  I think that there is one consideration that should be mentioned in this section:  Given that the largest value is preferred (2 = invalid), there is an attack vector where a router in the path (yes, even an internal router) can inject a community indicating that the route is invalid; the communities are not protected.  This action could result in inconsistent routing or in even a DoS.  I know the document is not explicit about what to do with the validation state (which is ok), but the clear intention (from rfc6811 and rfc7115) is that it will be used to make routing decisions.  Please add some text about this potential issue.
> 
> I started to write something about this and then realized I don't understand what you mean. At first I thought you were saying that an attacker that can forge an OV community can bias route selection. While this is true of course, it's also not unique to OV (Localpref has this property for example). It probably wouldn't be hard to write a sentence to summarize this, if necessary. 
> 
> However, you specifically refer to the invalid state: "a router in the path ... can inject a community indicating that the route is invalid". This makes me think you think there's something special about "invalid", and I don't know what it is. You also say something about the sorting order, which I'm also not sure why that would matter.
> 
> As far as I can tell, injecting "a community indicating that the route is invalid" is kind of boring attack -- it just makes the route less likely to be selected by the downstream router. The "bad" router could also just fail to propagate the route at all ("underclaiming") making it flat-out impossible for the downstream to select it, or could use any number of other path attribute manipulations (Localpref, AS path, etc) to make the route less preferable. Are you suggesting there is some fancier attack than this, or are you just asking us to acknowledge BGP doesn't work very well in the face of an on-path attacker?
> 
> By all means, if anyone has text to send, do.

you have out-sourced your security.  the party to which you have out-
sourced it can send you anything.  get over it.

as the OV signaling is vanilla bgp, there is no integrity enforcement,
not even a useless checksum; any monkey in the middle can fake anything.
get over it.

none of this is new.  you'll really love the wonderful new blackhole
community.

randy