Re: [sidr] [Idr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?)

Brian Dickson <brian.peter.dickson@gmail.com> Fri, 13 April 2012 22:05 UTC

Return-Path: <brian.peter.dickson@gmail.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 2BBF311E8132; Fri, 13 Apr 2012 15:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.12
X-Spam-Level:
X-Spam-Status: No, score=-3.12 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFHDaEJAbDVT; Fri, 13 Apr 2012 15:05:46 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6168B11E8130; Fri, 13 Apr 2012 15:05:45 -0700 (PDT)
Received: by wibhj6 with SMTP id hj6so5946771wib.13 for <multiple recipients>; Fri, 13 Apr 2012 15:05:44 -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=dfeaOQ2ILu+gazCrOKxXaLJNognTO5oRcfIyNK86Q/U=; b=ajYof+ZQo1A19O3N3Ad081KYFat1YHzVhN5UI4XyU5OLgUYHg1i7G9/FgnjhS9mX9f TrEx5d75tih+ecQVpPp2ry4Akdi7jhT/ZCkxvPdW6OKGnMWJCv+awMhuwUTaDdOIwaBJ WuBWo872tkqO60a4g0rXeFuNIxfbAQ81JM2iGN6QZJ48s6v5bK4aY8xAlpog92yYIM7h JnVCTXvs+so3Kg1IcqzqQZ4ZtwZJeLV6GguOVo9/XsuXaE0ZFmylvZQNbgx0Opji6Krj QsKAgoTnCcUWBNcJp1uIzi0okDzxLEbVvXBqrkEaUftMrmT4ONI1pPFCdjwbdahmCrnR phiA==
MIME-Version: 1.0
Received: by 10.180.95.129 with SMTP id dk1mr8528114wib.3.1334354744598; Fri, 13 Apr 2012 15:05:44 -0700 (PDT)
Received: by 10.223.88.212 with HTTP; Fri, 13 Apr 2012 15:05:44 -0700 (PDT)
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EE94001@EUSAACMS0701.eamcs.ericsson.se>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <D7CF4F8F-AF93-43F2-BC0D-26E072307B4F@kumari.net> <20120411142053.GA1283@slice> <7309FCBCAE981B43ABBE69B31C8D21391B3EE94001@EUSAACMS0701.eamcs.ericsson.se>
Date: Fri, 13 Apr 2012 18:05:44 -0400
Message-ID: <CAH1iCiqDMocKtyFSHH70jmBTRvw=1unQqzW3C3Pzy=bDswEaag@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Jakob Heitz <jakob.heitz@ericsson.com>
Content-Type: multipart/alternative; boundary=f46d0444ee2d8e634304bd96ac1a
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 13 Apr 2012 22:05:47 -0000

At the risk of opening a can of worms (or at least seeing a cylindrical
hollow metal labeled "Caution: contains worms")...

I believe the larger issue is, that Authentication is orthogonal to
Authorization.

As it currently stands, only Authentication has been given any
consideration, per se.

The two things being Authenticated are:
o  Origination (prefix + ASN, and maybe other identifying elements such as
IP addresses of routers), and
o   ASNs in the AS_PATH.

What is not explicitly being discussed, is, the question of "What is $foo
Authorized to do?".

E.g. The implicit assumption is, Only ASN==X is allowed to originate
prefixes whose AS_PATH "starts" (ends) with X.
And, the other implicit assumption is, the only thing any ASN is permitted
to do, is to prepend its own ASN to the AS_PATH, (zero or) one or more
times.

However, it may be worth considering all the other things that are done by
ASNs currently:
o   Private ASNs being stripped (private leaf ASNs)
o   Confederations
o   Route Servers
o   ECMP and friends
o   other vendor-specific or multi-vendor stuff being done to the AS-Path
(replace-as, as-sets, etc.)

Rather than dogmatically ignoring these issues, or declare them "out of
scope!!!",
I would prefer to see a rational discussion on whether there is a suitable
place in the system,
to facilitate some way of handling these cases, in a way that does not
weaken the security model.

Basically, rather than just say, "Okay, if you want to do this, turn off
BGPSEC", I think there is
value in saying, "To do this, you need to add $X to $Y to authorize this
activity", so that
RPs are able to reconcile what they receive, with what the RPKI-encoded
data says they
should expect.

For example:
Say that ASs A, B, and C, exchange routes via a route-server AS S.
Each of A, B, and C encode something that says, roughly:
"I am okay with NLRIs I send to S, have S omitted from the AS_PATH", and,
"I am okay with S sending me NLRIs that have S omitted, so long as the
immediate AS after S, also allows S to omit itself".
So, a signature block "R B S C Q" can be reconciled with an AS_PATH of "R B
C Q", by seeing the S sig,
and the rules for C->S and S->B allow this, established respectively by all
of C, S, and B.

The difference between this, and the whole "pCount==0" thing, is that the
above is an explicit policy encoded in the RPKI,
which can be validated more than one hop away from S.

The "pCount==0" logic is only truly verifiable by the immediate recipient,
and then only by the operator's personal implementation for enforcing local
policy (which itself be weak or faulty).

A recipient of an BGPSEC_Signatures_Block which has any pCount==0 in the
middle, currently has no way of ascertaining the legitimacy of that
occurrence.
The Signature Block (AS/N) of "R/1 B/1 S/0 C/1 Q/1" is consistent with an
AS_PATH of "R B C Q", but there is no way to know if this is in fact
sensible.

For other examples:
Private ASNs are, by definition, not unique.
However, it would still be nice to be able to identify their owners, e.g.
by IP address, and validate ASN substitutions by RPKI, based on
Origination/Signature data.

Proxy Origination would also be nice to have Authorization of Delegation
(to sign), possibly chained.
E.g. A delegates signature_origination to B, who delegates
signature_origination to C.
Prefixes assigned to A, could be signed by C, but would validate only if
the signed AS_PATH was "C B A".

I'm sure there are plenty of other use cases, which match up with actual
operator practices today.

If the mechanics of this can be done in a scalable and secure manner, this
will greatly enhance deployment likelihood, and ease deployment itself.

(This is where the IETF in general, can redeem itself for its past sins.
Don't ignore real needs, regardless of how tempting it is to keep designs
"pure".)

IMHO.

Brian

P.S. This kind of complex stuff really begs face-to-face meeting time. It
is hard to convey intent via messages. Oh, the irony...

On Thu, Apr 12, 2012 at 11:59 PM, Jakob Heitz <jakob.heitz@ericsson.com>wrote;wrote:

> On Wednesday, April 11, 2012 7:21 AM, Jeffrey Haas <> wrote:
>
> > In the case where the paths are not congruent (which shouldn't happen
> > unlike the AS4_PATH case in RFC 4893 - we don't tunnel bgpsec across
> > other BGP), we probably have some sort of hard error case.  One
> > reasonable assumption is
> > that a non-BGPSEC speaker mucked with the AS_PATH - perhaps an iBGP
> > speaker doing path manipulations for policy.  IMO, the proper
> > behavior here is to *not* propagate the route at a BGPSEC ASBR
> > boundary; any BGP speaker that manipulates the AS_PATH in such a way
> > as to break the congruency of ASes between AS_PATH and signature MUST
> > be a BGPSEC speaker.
> >
> > The above still doesn't deal with common deployment considerations
> > such as as-override, replace-as and remove-private.
>
> This just highlights the semantic difference between the BGPSEC
> path and the AS_PATH.
>
> They may be different legitimately. This is why we need both.
>
> A receiver can make its own decision whether the difference
> between the paths should cause path invalidation or not.
> If a sender is legitimately manipulating an AS_PATH, then the
> receiver should know about it and use this knowledge to help
> in the decision.
>
> --
> Jakob Heitz.
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>