Re: [secdir] New Routing Area Security Design Team

Jeffrey Haas <jhaas@pfrc.org> Sun, 22 April 2018 22:54 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 9DE2D127010 for <secdir@ietfa.amsl.com>; Sun, 22 Apr 2018 15:54:56 -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 XAqVrMhNTjsk for <secdir@ietfa.amsl.com>; Sun, 22 Apr 2018 15:54:54 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3362E1200FC for <secdir@ietf.org>; Sun, 22 Apr 2018 15:54:54 -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 2DC561E401; Sun, 22 Apr 2018 18:55:57 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E7A49EC9-E6F5-4BCF-B3EE-3294789C30DC"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <CAL02cgSa+1_BhZ1zBbNo2aAHLemhwYnEA-KBjhw8evmOmT7POQ@mail.gmail.com>
Date: Sun, 22 Apr 2018 18:54:52 -0400
Cc: Christian Huitema <huitema@huitema.net>, Sean Turner <sean@sn3rd.com>, Russ White <russ@riw.us>, Stewart Bryant <stewart.bryant@gmail.com>, "Acee Lindem (acee)" <acee@cisco.com>, "BRUNGARD, DEBORAH A" <db3546@att.com>, secdir <secdir@ietf.org>
Message-Id: <BDDBD41E-774A-46A8-A67A-3B428B2FB08B@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> <97CBB44D-3236-405C-B62C-C3BEF8DB933D@pfrc.org> <1c18b4e6-d7ba-1d63-ba53-9292995ad7b0@huitema.net> <CAL02cgSa+1_BhZ1zBbNo2aAHLemhwYnEA-KBjhw8evmOmT7POQ@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/J0XP96W4jLkXUvucjmWF5CKxWhU>
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 22:54:56 -0000

> On Apr 22, 2018, at 6:51 PM, Richard Barnes <rlb@ipv.sx> wrote:
> 
> 
> 
> On Sun, Apr 22, 2018 at 6:17 PM, Christian Huitema <huitema@huitema.net <mailto:huitema@huitema.net>> wrote:
> On 4/22/2018 2:57 PM, Jeffrey Haas wrote:
> 
> > 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.**
> 
> That's actually part of the secure transport selection problem. TCP-MD5
> and TCP-AO are not used a lot outside of BGP. They may be standardized,
> but they are not really "mainline". And as such, you may or may not find
> it available in your OS of choice. And as you write, as BGP developer
> you have little control over that. Mainline applications are content
> with TLS, but that won't solve the TCP-RST issue that you are concerned
> about. IPSEC will solve it, but at the cost of interesting management
> issues. I really wonder whether the practical solution might be to
> standardize on a transport like QUIC that runs over UDP. Of course, QUIC
> is not really mainline, at least not yet. But the code can be compiled
> with the application, independently of the OS. So as a BGP developer,
> you could just ship it with your code. You would in fact control the
> transport stack that you use.
> 
> This seems like a really useful analysis approach.  The bias in this work should be toward transport protocols that other apps use -- since in the context we're talking about here, routing is just another application.  So we should start with the default, mainline protocols (TLS, IPsec), and look at where they don't fit.
> 
> In otherwords: I would prefer to see this group not have as a goal "Universal deployment of TCP-[MD5|AO]", but rather "Removal of custom hacks from the ecosystem and replacement by a more mainline protocol".   Let's bring routing protocols into the applications fold to the greatest degree possible.

I'm quite supportive of this.  See my slides. :-)

As I mentioned earlier in the thread, a goal is to simply clarify the common scenarios and boilerplate them.  If we can address this through profiles on existing solutions - so much the better.  As part of the discussion, however, operational considerations need to be considered very strongly.

-- Jeff