Re: [sidr] Levels of BGPsec/RPKI validation, was: Re: [Idr] wglc for draft-ietf-sidr-bgpsec-protocol-11

Matthew Lepinski <mlepinski.ietf@gmail.com> Thu, 30 April 2015 17:48 UTC

Return-Path: <mlepinski.ietf@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149531A889F; Thu, 30 Apr 2015 10:48:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.31
X-Spam-Level: *
X-Spam-Status: No, score=1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=0.922, SPF_PASS=-0.001] autolearn=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 hZnGzwQPq7s8; Thu, 30 Apr 2015 10:48:23 -0700 (PDT)
Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (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 990931A8A51; Thu, 30 Apr 2015 10:48:19 -0700 (PDT)
Received: by obbeb7 with SMTP id eb7so49974811obb.3; Thu, 30 Apr 2015 10:48:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zwKsdSEiK2Ppt9wyA5MrVm2uf/UOyQshvIffJxbgBeE=; b=0644APAOzt++GRUwow5YpDVDSPa2DvEvr3JVuCniYv2rK9PDxdds06hgTv0iHcui1y QxxxAUK6+kgimdSsHKjQ5oP0fZVTpYp2EbAAHoOv5aVgqxtJBSsSdb1Kn8hVEWEZN2lP Sxo4d6a30h/l6O/YjdtWmT2wA+u7nanL/EJO140jlzGlmgi9CR5gDsJRdDaYVyishRgX VIBICKG/xGDxzqn6xnWvh/GeX3p1m3IGq+i/EmPBM9ZLDmIDfEx5/O3fqDZXEjFKenUo 2LU8h56BVa4BYDN2Ki9jUSSGHPcbd4KaOmAXHkSAFddeRzYWano4tPsSkmuO4tqVziZb C5jg==
MIME-Version: 1.0
X-Received: by 10.182.153.74 with SMTP id ve10mr4349928obb.54.1430416098990; Thu, 30 Apr 2015 10:48:18 -0700 (PDT)
Received: by 10.202.226.13 with HTTP; Thu, 30 Apr 2015 10:48:18 -0700 (PDT)
In-Reply-To: <ECDAD8F2-1C27-4494-887C-59280D7FF973@muada.com>
References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <ECDAD8F2-1C27-4494-887C-59280D7FF973@muada.com>
Date: Thu, 30 Apr 2015 13:48:18 -0400
Message-ID: <CANTg3aC4EurFpEP9S+5v4L5mz4zO2TLf9jOn+biCv0knms=8=Q@mail.gmail.com>
From: Matthew Lepinski <mlepinski.ietf@gmail.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>
Content-Type: multipart/alternative; boundary="089e013a0ba87620580514f4b3ed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/K0TywGx9G_n-GsABUl-uWgmhgwU>
Cc: "idr@ietf.org wg" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>, ggm@apnic.net, Sandra Murphy <sandy@tislabs.com>
Subject: Re: [sidr] Levels of BGPsec/RPKI validation, was: Re: [Idr] wglc for draft-ietf-sidr-bgpsec-protocol-11
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 30 Apr 2015 17:48:26 -0000

Iljitsch,

Thank you for the feedback. With regards to bgpsec-protocol and/or
bgpsec-overview, I am not sure what text would be helpful.

For path validation (as opposed to origin validation), the path validation
algorithm returns one of two states. That is, either an update has a valid
signed path or it doesn't. (We discussed previously in SIDR whether there
was a useful third case for path validation, and the working group wasn't
able to come up with one.)

This means that there are six possible states that come from SIDR
validation (assuming you are using both origin validation and path
validation). That is, three possible origin validation states and two
possible path validation states yields six possible joint states. Of
course, one's local policy is free to collapse that state-space if they
wish to treat of some of those states as identical. (Perhaps if origin is
invalid, then it doesn't matter whether path is valid or not ... maybe it
is foolish to care about whether there are signatures on a path if the path
is headed to a bad destination. I don't know ... but it is a matter of
local policy, and it is perfectly fine for different operators to handle
such cases differently.)

In any case, with regards to path validation, I think that in general  one
wants to prefer routes with valid, signed paths over routes that lack
valid, signed paths. However, personally, for path validation, I would not
recommend throwing out all route advertisements where path validation
returns invalid. That is, if the only route you know of to get to a
particular block of address space has a signature that doesn't valid (or
lack signatures because someone in the middle doesn't have BGPsec turned
on), I think it is probably a good idea to use that route despite the lack
of valid signature chain. (But again, this is a matter of local policy, and
I don't want to mandate policy decisions for network operators in the base
protocol specification.)

- Matt Lepinski


On Tue, Apr 28, 2015 at 2:01 PM, Iljitsch van Beijnum <iljitsch@muada.com>
wrote:

> On 28 Jan 2015, at 23:38, Sandra Murphy <sandy@tislabs.com> wrote:
>
> > idr folk, your attention and comments would be appreciated as well.
>
> Since you ask...
>
> I'm sending this to both idr and sidr as I think this needs broader input
> than just sidr. (And it seems I'm no longer on the sidr list.)
>
> I read draft-ietf-sidr-bgpsec-protocol-11 and
> draft-lepinski-bgpsec-overview-00.txt as well as RFC 6483.
>
> I think what's lacking here is any discussion of what happens when
> certificates etc expire. Please stay with me for a bit:
>
> RFC 6483 talks about RPKI route validation, which suggests that there are
> three possible states:
>
> valid
> unknown
> invalid
>
> where valid is preferred over unknown and unknown over invalid, and:
>
> "It is a matter of local routing policy as to whether routes with an
> "invalid" validity state are considered to be ineligible for further
> consideration in a route selection process."
>
> Actually, I think the only reasonable approach is to filter out invalids
> and prefer valids over unknowns. The important part here is that if there's
> a ROA for 193.0.0.0/21 and then someone announces a more specific like
> 193.0.7.0/24, that /24 will be "invalid", so even in partial deployment
> RPKI users are protected against malicious or accidental more specifics.
> But if invalids are accepted, even with a very low preference, then they
> still get to divert traffic.
>
> So far, so good.
>
> But now what if a certificate expires? We know from the web that this is
> extremely common. If an expired certificate means the prefixes involved are
> marked invalid, this means that filtering invalids becomes very
> problematic: not only will prefixes randomly drop off the net as people
> forget to generate or install certificates or RPKI caches get stale, but if
> things get really bad the resulting lack of connectivity makes it
> impossible to correct the problem...
>
> So what we need is for expired certificates to make the affected prefixes
> revert to unknown rather than invalid. Turns out, that's what happens today:
>
> http://mailman.nanog.org/pipermail/nanog/2014-December/071907.html
>
> However, unless this is specified in one of the related documents other
> than the three mentioned above, this seems to be an implementation choice.
>
> I think the above issue needs to be discussed in an update of RFC 6483 or
> in one of the BGPsec documents.
>
> And there's probably a bit more to think about: wouldn't it make sense to
> be able to filter on the signature algorithm at some point during the
> transition from one algorithm to the next? Or to be able to filter on
> "expired" explicitly? A binary valid/invalid isn't enough.
> Valid/unknown/invalid is workable, but maybe four or five levels is even
> better.
>
> (And have a look at how this works in practice:
> http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/command/irg-cr-book/bgp-m1.html
> search for PEX.)
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>