Re: [secdir] New Routing Area Security Design Team

Christian Huitema <huitema@huitema.net> Sun, 22 April 2018 22:17 UTC

Return-Path: <huitema@huitema.net>
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 C65D2126D85 for <secdir@ietfa.amsl.com>; Sun, 22 Apr 2018 15:17:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 SEbd65MJ_n9K for <secdir@ietfa.amsl.com>; Sun, 22 Apr 2018 15:17:41 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860E91200FC for <secdir@ietf.org>; Sun, 22 Apr 2018 15:17:41 -0700 (PDT)
Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx60.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1fANIg-000Fxm-NL for secdir@ietf.org; Mon, 23 Apr 2018 00:17:39 +0200
Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1fANIb-00022S-Gq for secdir@ietf.org; Sun, 22 Apr 2018 18:17:34 -0400
Received: (qmail 29388 invoked from network); 22 Apr 2018 22:17:30 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.78]) (envelope-sender <huitema@huitema.net>) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for <acee@cisco.com>; 22 Apr 2018 22:17:30 -0000
To: Jeffrey Haas <jhaas@pfrc.org>, Sean Turner <sean@sn3rd.com>
Cc: "BRUNGARD, DEBORAH A" <db3546@att.com>, secdir <secdir@ietf.org>, Russ White <russ@riw.us>, Stewart Bryant <stewart.bryant@gmail.com>, "Acee Lindem (acee)" <acee@cisco.com>
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>
From: Christian Huitema <huitema@huitema.net>
Openpgp: preference=signencrypt
Message-ID: <1c18b4e6-d7ba-1d63-ba53-9292995ad7b0@huitema.net>
Date: Sun, 22 Apr 2018 15:17:16 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <97CBB44D-3236-405C-B62C-C3BEF8DB933D@pfrc.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 168.144.250.190
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.14)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5vh99GZ83ZBAilYCxXHA7zZ602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzniiMFxnOFMHTZqw+apvQzTV/3OdXD2Xdo8CfrY5CQS2/HfDCF3+BO7LhlaThPf4oyz NJVaeAWax4WOe4pTBX2DwIE7VKe+bqpcdCns72R16Duyz4UD14ePeUAPER8QDaXe0Of4jddu9xC8 8+iQ5nb6BRFVjXUbiREH8mlR1JtP/UPTAAMnNuB6/0WWjH77oh6ijzwzq5HGxV3pRhOdYuobeA2G NaAif0QyGEAJd8kel+zffa+S3paXsykGResyE7dAzbZabvf4+eAvvSn0D5YzxzA4C4+ILjmdkQoL 6F7cCSavQBrPoagEXfZ210Cx8bwqyT5p50x81ZKcmzCu2U1l0pLLr6Q2GfeLeJGF+80D4WY7xWSn pVjQVprFFOt2hDWKtLT9WR57oxUvRixjadcobnduoQv5Sp6y3SmK1n5SMPepZn00xVXQbuUt1pns FwEiRQv+PVjjwa+Z5RFCOMTpZO2F7gR9fPNnztJleHauSrAWlToiTWgG7mSH912JHX9vOwe8e8rd vCGSYFH6igGU2yw6z85L3UyCdO+oQ3S7VPd90DA1c/ZLOZZo7XGPVfWv8HL1YL3Zn8TE/e4IMjT6 4dZYZAAUgQSn0n4YsmwR9pozWdbw56YFdP5Q2QyzPOggKW28pboyZCmKkHUYXanYpLuxjuBVBgpa uPkPLIoHdMvNN8GmDerZ4JeMOBsC9HtB4/4Pbrz2QtFuyl+Sh6eSsUPc54JCDDPrhwG8vzFYfqb5 R4VemuUI6bcEARsm0KnLtMabt6P+t78klMitoc+NZy58uobCIkCdwVDO83SGTnM2K/9iKCD9v589 nVS3hWSdEOMftBjsWb6BDQzjSsHUIomTnJwT4ky6b7E7Hukt2Ge4B8NG0VKlrY+34Zmj+F/tjlrZ UvGhhjiSam0tWhQxL7hrJSk60SF3F6RYOYr2
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/4OR9lrDzhYkhdeOLQfoU2bSXj3U>
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:17:44 -0000

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.

-- Christian Huitema