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

David Mandelberg <david@mandelberg.org> Tue, 28 April 2015 22:21 UTC

Return-Path: <david@mandelberg.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841021A8BC5 for <idr@ietfa.amsl.com>; Tue, 28 Apr 2015 15:21:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 h0YkBHIQ4ebo for <idr@ietfa.amsl.com>; Tue, 28 Apr 2015 15:21:14 -0700 (PDT)
Received: from nm6-vm6.access.bullet.mail.bf1.yahoo.com (nm6-vm6.access.bullet.mail.bf1.yahoo.com [216.109.114.149]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A667C1A8BB2 for <idr@ietf.org>; Tue, 28 Apr 2015 15:21:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1430259673; bh=6I/k2NQ/CL91na9BrT5QS8KXRA3swNO1TMtoeAfqKlI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From:Subject; b=SMIiaquxFh6hPXtoJgnke+Hcsv09I3bTb0SaiCpM5RtERtycePzIYlDzvPjFWK692DpNxz87kQxzPGI7vBORtH1UcmQKK1nIIQq4tHGuuKjTcnnQm8nqbJxUOAeS9qXK2V2I4rWGoHkajCwrqI0eGoI8/YfYqkYGJw4Yc5sWo6uiIlXvsqPNitoRlyyfx+XKojXmK5ePXMwrrKaKQ6GESepHJIY+Orqhxa9CQ1AFn1Dmq5s3tGHtcUW+BNB8hjiSuyioMy9bRTJG/HraO4tgsbogsR4mfxc06ts+KGbs9HCQnu1zgtg3gDMZiZLuXJd9xuoGgqnVQ7UodaDppvxmhw==
Received: from [66.196.81.156] by nm6.access.bullet.mail.bf1.yahoo.com with NNFMP; 28 Apr 2015 22:21:13 -0000
Received: from [98.138.104.99] by tm2.access.bullet.mail.bf1.yahoo.com with NNFMP; 28 Apr 2015 22:21:13 -0000
Received: from [127.0.0.1] by smtp119.sbc.mail.ne1.yahoo.com with NNFMP; 28 Apr 2015 22:21:13 -0000
X-Yahoo-Newman-Id: 682213.69154.bm@smtp119.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: DWQpn2UVM1lAL_QXtCqVK74Mwm5wL1HTJ9mQAxAFTEt1KTg hTvA_0y5zul1R0ukqK9FnryjFv4klzWST6O2j6hbF31v_wiL8iCDZNbAIj34 67tVo3QrUlD73pelxZMv935fkqlEiiPoeI7iHnWOZX3ljNo5INi__mvtYfVQ j65JzQkPQ9oaLboypRPaEaVfifImQ_jCZ9kNB64m1b9Hf3N0fq6MJhVJpmMa wqcYrMW0lZitA.buzFA76vLY4IPD7bDqNf6LkQc6KduthUtgu.GD5Wx.hLYM u_sxru7VbptDLmXqRh2DpxU6tN1cqxsz383c7lUQHIXfnvn2SjUdRKKtCixv zFuans2FBSWnv7Ou8AJRJCQ0QRWZrVSUSgG4UTs8uZJgRUOxUmN7r2OmiTZu ko8QAKc7CA3LtuKdrC2i8tTYMqiMEc2rCXiht3R6h819QSds.uDqzipdNBB6 MQwcMWYXrfekS6ClaAH_oPmA6oZZEboEThwzmPSn3JyP5CnCkNluogHJCnLN w6gbogsaogizEC.P09yIVoTKlRQ--
X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708-
Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 4EEE81C6048; Tue, 28 Apr 2015 18:21:12 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Tue, 28 Apr 2015 18:21:12 -0400
From: David Mandelberg <david@mandelberg.org>
To: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <B1EDF7B6-1E42-440E-BD3F-29723AD7E4A4@muada.com>
References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <ECDAD8F2-1C27-4494-887C-59280D7FF973@muada.com> <EF4348D391D0334996EE9681630C83F02D173BEB@xmb-rcd-x02.cisco.com> <B1EDF7B6-1E42-440E-BD3F-29723AD7E4A4@muada.com>
Message-ID: <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org>
X-Sender: david@mandelberg.org
User-Agent: Roundcube Webmail/0.7.2
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/yu9OBPscRu-CZ8lB5y3lYa45AZQ>
X-Mailman-Approved-At: Wed, 29 Apr 2015 08:04:35 -0700
Cc: idr@ietf.org, sidr@ietf.org
Subject: Re: [Idr] [sidr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Apr 2015 22:21:16 -0000

On 2015-04-28 15:21, Iljitsch van Beijnum wrote:
> On 28 Apr 2015, at 20:27, Roque Gagliano (rogaglia)
> <rogaglia@cisco.com> wrote:
>
>> It is not an implementation choice, it is by design. If a signed 
>> object does not validate (based on whatever reason not just 
>> expiration), it is like if did not existed.
>
> No...
>
> Suppose:
>
> ROA: 193.0.0.0/21 up to /21 -> AS 3333 not valid after 20150430

In your example, is this the only ROA with a prefix that covers 
193.0.0.0/21 or is covered by 193.0.0.0/21? Based on the states below, 
I'm assuming it is. Please correct me if I'm wrong.


> BGP table 29 april:
>
> 193.0.0.0/21   3333 -> valid
> 193.0.0.0/21   4444 -> invalid
> 193.0.7.0/24   3333 -> invalid
> 192.0.0.0/16   5555 -> unknown

This part looks right to me.


> But, two days later, after the ROA expires, do we have this:
>
> 193.0.0.0/21   3333 -> unknown
> 193.0.0.0/21   4444 -> unknown
> 193.0.7.0/24   3333 -> unknown
> 192.0.0.0/16   5555 -> unknown
>
> or this:
>
> 193.0.0.0/21   3333 -> invalid
> 193.0.0.0/21   4444 -> invalid
> 193.0.7.0/24   3333 -> invalid
> 192.0.0.0/16   5555 -> unknown
>
> ?
[snip]
> But the real issue is that this isn't written down anywhere as far as
> I can tell, so we're dependent on implementers all independently
> coming up with the preferred way to handle this. That's never good
> business for a standards organization.

It's the first one (all unknowns). I don't think this is written down 
explicitly, but if implementations follow RFC6483, I don't think there's 
any way they can get the second result.

 From RFC6483, Section 2:

    It is assumed here that a relying party (RP) has access to a local
    cache of the complete set of valid ROAs when performing validation 
of
    a route.  (Valid ROAs are defined as ROAs that are determined to be
    syntactically correct and are signed using a signature that can be
    verified using the RPKI, as described in [RFC6482].)  The RP needs 
to
    match a route to one or more valid candidate ROAs in order to
    determine a validation outcome, which, in turn, can be used to
    determine the appropriate local actions to perform on the route.

This means that only valid (non-expired) ROAs are used for origin 
validation. Like Roque said, "if a signed object does not validate 
(based on whatever reason not just expiration), it is like if did not 
existed."

Then, in the next paragraph:

    However, routes
    for address prefixes that are not fully described by any single ROA
    (i.e., those routes whose address prefixes may be an aggregate of
    address prefixes described in a valid ROA, or have address prefixes
    where there is no intersection with any valid ROA), and are not
    matched by any valid ROA and do not have an address prefix that is a
    more specific address prefix described in any valid ROA, cannot be
    reliably classified as "invalid" in a partial deployment scenario.
    Such routes have a validation outcome of "unknown".

Since the {AS 3333, 193.0.0.0/21-21} ROA expired, there's no *valid* 
ROA that intersects any of {193.0.0.0/21, 193.0.0.0/21, 193.0.7.0/24, 
192.0.0.0/16}. (See my assumption above about no other ROAs for these 
prefixes.) Since none of these four prefixes intersect any prefix in any 
valid ROA, all four routes you gave are unknown.

Based on the two snippets above, I do think it's clear enough for 
implementations to get it right. However, you asked a good question that 
other people will probably ask again. Do you think it would be helpful 
to make this case more explicit somewhere?

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/