IETF Logo Mail Archive

Re: [sidr] [Idr] Route Leaks and solutions

Christopher Morrow <morrowc.lists@gmail.com> Mon, 20 July 2015 14:22 UTC

Return-Path: <christopher.morrow@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 1A5091A897B; Mon, 20 Jul 2015 07:22:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] 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 G9K2PIjj8C3q; Mon, 20 Jul 2015 07:22:10 -0700 (PDT)
Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (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 D5DBE1A8974; Mon, 20 Jul 2015 07:22:09 -0700 (PDT)
Received: by ykax123 with SMTP id x123so140041961yka.1; Mon, 20 Jul 2015 07:22:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZS8uBIy39oIHPOnxSQyTg3xqMquaYNtX6h63IWp7mqk=; b=UTJknqCSMcqVOb8jZiMGS0hucT5zeS5Ksm0HRgJxxn7USUId6U9xf1MOmzJG43FeA8 8G43FlOY6lKndkfEgU0q9Ec7o8p8DcWjGf++Cn81zEl46Q/nbx9QGE4RGMuXSMIRY4BO RnPbS04Yo8puCtVgMQ6tPA5zcsAKGKoD6Kmt1zYasFUR9nuKlPvO3ELfBsEP2o9HsCvc N3abJr1BE7G5S7Wbj1oHKR6Lt8SNWGofeg3jP7YB31xWRSwLpbSoT/+hX7WSCG18M1b5 Fix02ahT5W7gAitoEMHg50HZsBGkMgQClEq5JafWSPiqJAwrw7vLo1ERAJJHIdhyBPuB +eWw==
MIME-Version: 1.0
X-Received: by 10.13.236.5 with SMTP id v5mr28516053ywe.138.1437402129199; Mon, 20 Jul 2015 07:22:09 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.13.228.196 with HTTP; Mon, 20 Jul 2015 07:22:09 -0700 (PDT)
In-Reply-To: <CY1PR09MB0793E39F703D436A3E21805B84900@CY1PR09MB0793.namprd09.prod.outlook.com>
References: <005901d0b283$ea07bd20$be173760$@ndzh.com> <m2fv52b1w1.wl%randy@psg.com> <CY1PR09MB07939BA36BB01C19AD9AC2A384930@CY1PR09MB0793.namprd09.prod.outlook.com> <CAL9jLab5LOfeSYGzt=ywAwkoJdbe4moXD2w5LsGF-L_Cju_TUw@mail.gmail.com> <CY1PR09MB0793E39F703D436A3E21805B84900@CY1PR09MB0793.namprd09.prod.outlook.com>
Date: Mon, 20 Jul 2015 10:22:09 -0400
X-Google-Sender-Auth: _wHo3cPH6zn29CLZRF5n8Pnr8eM
Message-ID: <CAL9jLaZP1kprSrRZCDif2_9NJnComdzJox9PThh0FqKSJ96bPw@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/1uO3TdzGpB13L_C354mQTRw0Sg4>
Cc: idr wg list <idr@ietf.org>, "sidr wg list (sidr@ietf.org)" <sidr@ietf.org>
Subject: Re: [sidr] [Idr] Route Leaks and solutions
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: <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: Mon, 20 Jul 2015 14:22:11 -0000

I think I see the current plan as a it challenging to depend upon...

If the RLP bit is dependent upon ops folks getting the right
config-bit set for each customer we would want that to be as much
automated as possible so there would be the least chance for 'forgot
to set the bit' or 'set bit incorrectly'.

I'm worried that I can't tell reliably what the bit was 2 as-hops
away, did they mean 'customer' ? or was that a mistake? Did someone
change it mid-path to me? Did the implementation of their vendor gear
change/set the wrong attribute value?

There seem to be a bunch of uncertainties with this, in my mind. I
guess that with bgpsec signing this attribute at least 'joe really
meant that jim was his customer', and you can't change the value on a
bgpsec path.

If we want that, I think having the attribute where it can get changed
(not-bgpsec secured paths) is a real problem, or opens up some pretty
large problems...

v2.23.0 | Report a Bug | By Email