Re: [secdir] New Routing Area Security Design Team

Jeffrey Haas <jhaas@pfrc.org> Sun, 22 April 2018 21:57 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 7485E126C26 for <secdir@ietfa.amsl.com>; Sun, 22 Apr 2018 14:57:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.387
X-Spam-Level:
X-Spam-Status: No, score=-0.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no 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 8FQpDd7_iazo for <secdir@ietfa.amsl.com>; Sun, 22 Apr 2018 14:57:22 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 988071200F1 for <secdir@ietf.org>; Sun, 22 Apr 2018 14:57:22 -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 8DD371E401; Sun, 22 Apr 2018 17:58:25 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <CABBF7D4-2B9B-4403-9C00-63C76906E631@sn3rd.com>
Date: Sun, 22 Apr 2018 17:57:21 -0400
Cc: Richard Barnes <rlb@ipv.sx>, secdir <secdir@ietf.org>, Russ White <russ@riw.us>, Stewart Bryant <stewart.bryant@gmail.com>, "Acee Lindem (acee)" <acee@cisco.com>, "BRUNGARD, DEBORAH A" <db3546@att.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <97CBB44D-3236-405C-B62C-C3BEF8DB933D@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> <0B9DB69A-472E-4FF5-9164-FCFB59C26D64@pfrc.org> <CABBF7D4-2B9B-4403-9C00-63C76906E631@sn3rd.com>
To: Sean Turner <sean@sn3rd.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/wNakcQ-rPIsllmsW-RjEiZCEoxs>
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: Sun, 22 Apr 2018 21:57:24 -0000

> On Apr 20, 2018, at 10:36 PM, Sean Turner <sean@sn3rd.com> wrote:
> 
>> On Apr 16, 2018, at 10:28, Jeffrey Haas <jhaas@pfrc.org> wrote:
>> 
>> 
>>> How about "Better Routing Application Transport Security (BRATS)"?  ;)
>> 
>> Only if we get our own line of dolls.
> 
> that maybe a better name is:
> 
> PEDICURE	PixiE Dust routIng seCURity considErations
> 
> Because, it sounds like that’s where we’ll be looking ;)  A nice side effect of this effort is that routing drafts can start to skip secdir reviews after this is done because whatever this group comes up with is going to get copied everywhere; it’ll be like MIB security considerations!  I assume that’s really the short term plan right?
> 
> I’m trying to not be too much of downer here, but the last time security helped there was a lot of: you don’t understand how these protocols are used/deployed, key management is too onerous, and whoa that’s too heavy weight/gold plated.  Since the last time around security still doesn’t come for free and pretty much every security protocol still requires some type of key management … so what’s going to be different this time around?  I.e., why would one want to volunteer to help one of these to be formed small teams?

Let me complete being a downer here.  Or at least further advance it.

Yes, the goal is to end up with a lot of copy and paste.  If you're not tired of being on the security side of the discussion saying "this document is missing transport security considerations" and having to go through a tedious dance with those who don't understand them?  Well... I can't see that you're not.  This response is exactly what I'd expect to see.

You'll also see I'm not pushing this as "all security considerations".  Transport - to start.  Because that's something most routing folk will grok and has a chance (see my slides) at being deployable - at least in some circumstances.*

Examples being use of TCP-AO so that things like key management can be done.  And pointers to good key management practices.  And without having to have this exact discussion with every single document author every single time.  Unless you really enjoy having this discussion repeatedly, in which case we can all go back to doing things exactly as they're done today. :-)

As I point out in my slides, a significant part of this headache is an ecosystem issue.  I write mostly BGP related software as part of my day job.  I'm aware of better security practices.  I don't control the TCP/IP stack I get to use - and these things are not implemented in our routing suite.  Yelling at me to have better security at those layers is a NOP; at best I pass them back up to product managers to get it done in the people who manage those layers.**


-- Jeff

* See karp bootstrapping issues.  We didn't make a ton of progress for Reasons.  Lots of good analyses and followups from that though.

** TLS can be used in places when appropriate, and that's effectively in control of some devs working on control plane.  However, the operational considerations often means that it's not a wise choice.

> 
> spt
> 
> * for some value of help.