Re: [secdir] New Routing Area Security Design Team

Jeffrey Haas <jhaas@pfrc.org> Mon, 16 April 2018 14:28 UTC

Return-Path: <jhaas@pfrc.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3761A12D96D for <secdir@ietfa.amsl.com>; Mon, 16 Apr 2018 07:28:48 -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, HTML_MESSAGE=0.001, 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 UECBvC124kk6 for <secdir@ietfa.amsl.com>; Mon, 16 Apr 2018 07:28:46 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1481200C5 for <secdir@ietf.org>; Mon, 16 Apr 2018 07:28:46 -0700 (PDT)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id A85DA1E401; Mon, 16 Apr 2018 10:29:38 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_56DEB518-9E95-4595-AFDC-11C7ADD4E5EE"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <CAL02cgQaUGi7uq3GA4kdE54z2AUCOqBNYjbYsZT_wAsH-4aYgQ@mail.gmail.com>
Date: Mon, 16 Apr 2018 10:28:44 -0400
Cc: Russ White <russ@riw.us>, Christian Huitema <huitema@huitema.net>, Stewart Bryant <stewart.bryant@gmail.com>, "Acee Lindem (acee)" <acee@cisco.com>, "BRUNGARD, DEBORAH A" <db3546@att.com>, secdir <secdir@ietf.org>
Message-Id: <0B9DB69A-472E-4FF5-9164-FCFB59C26D64@pfrc.org>
References: <F64C10EAA68C8044B33656FA214632C8882C74A7@MISOUT7MSGUSRDE.ITServices.sbc.com> <CAL02cgS9rZKVtZs4aRWJmaQj-anaSqYj8rn8roDdxP+JhBR++A@mail.gmail.com> <F64B6EFA-1CB3-454B-B827-B5886A723D36@pfrc.org> <d37721c3-8e78-6eb8-c0ae-ba0e57a623c3@huitema.net> <026301d3d4e4$380d8b00$a828a100$@riw.us> <209F0EB5-AC41-4D00-8FE6-755802946061@pfrc.org> <CAL02cgTOOVXUXmvoE4JK97i8EeYnHevk4V9ecTepGLcB1YA-2w@mail.gmail.com> <2AD240AE-DF39-4D76-8D6B-BB8AADC6C267@pfrc.org> <024301d3d588$2b8ac6a0$82a053e0$@riw.us> <CAL02cgQaUGi7uq3GA4kdE54z2AUCOqBNYjbYsZT_wAsH-4aYgQ@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/b0p5U092r4Y-Dfu16_pR-CCkHws>
Subject: Re: [secdir] New Routing Area Security Design Team
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Apr 2018 14:28:48 -0000

> On Apr 16, 2018, at 9:54 AM, Richard Barnes <rlb@ipv.sx>; wrote:
> On Mon, Apr 16, 2018 at 9:38 AM, Russ White <russ@riw.us <mailto:russ@riw.us>> wrote:
> Until the IETF starts listening to folks beyond BGPSEC supporters, and rethinks what needs to be solved, the IETF will continue to play essentially no role in moving any solution for this problem forward. Hint: ensuring the "proper operation of BGP" is not a good starting point. 
> 
> I'm fully willing to admit that there has been some intransigence on the security side of things.  And I'm not trying to argue for BGPSEC in particular, but for solving the problem.
> 
> However, the messages in this thread make me think there's not really a willingness in the routing community to engage seriously in the problem either.

What I believe you're seeing is at least two veterans of the bgp security war saying they've done enough bleeding on that specific topic for a little while. 

>   Security mechanisms exist to enforce invariants, so if you're not willing to concede that BGP should adhere to some invariants (which is how Jeffrey's bullet points read to me), then you're never going to be able to meaningfully secure the protocol, and we should publish an RFC that says "here's the security properties you can expect of BGP lolz #YOLO CAVEAT ROUTOR" -- like RFC 4272, but more honest.

More emphasized below.  However, we didn't approach this as "let's secure BGP".  Matter of fact, BGP wasn't even what we were here to talk about.  Yet that's all this thread has devolved to.

> So maybe this group needs a more focused title :)

My opening message was "this group is mis-chartered". :-)

>   Because as this thread demonstrates, when you say "Routing Area Security", people are going to think you're going to solve actual problems with the security of routing, not just better transport security -- which really has nothing to do with routing, it's just securing the routing protocol as an application.

Bingo.

If you want more ocean boiling, let's do that later on.  For now, we have narrower work we'd like to focus on.  We believe it'll have value to the overall IETF community and should make part of the security review of RFC targeted documents easier.

> How about "Better Routing Application Transport Security (BRATS)"?  ;)

Only if we get our own line of dolls.

-- Jeff