Re: [secdir] New Routing Area Security Design Team

Richard Barnes <rlb@ipv.sx> Mon, 16 April 2018 12:13 UTC

Return-Path: <rlb@ipv.sx>
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 843231241FC for <secdir@ietfa.amsl.com>; Mon, 16 Apr 2018 05:13:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level:
X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
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 Bo1oev3CSha1 for <secdir@ietfa.amsl.com>; Mon, 16 Apr 2018 05:13:19 -0700 (PDT)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4252B126E64 for <secdir@ietf.org>; Mon, 16 Apr 2018 05:13:19 -0700 (PDT)
Received: by mail-oi0-x22f.google.com with SMTP id e123-v6so14250244oih.13 for <secdir@ietf.org>; Mon, 16 Apr 2018 05:13:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LUdyyOq3AV9hQKPqM4MkK9JMEAG65x0BoSsVBE+ksKA=; b=19jTIrEf/iPUw4cESR5rgtxJHcJZG/OT/H6C/jjqvvJ7JmOOb8g86Up3Va1F/8u8bo Rv/bj5u8iJqEyfKDfkfbc9nbncb96HQqe4lzhU3c7ITE3cqUL6jrY8399PqTiZKnT5Hi X8fwnDhI5oG2Ch7alxp7KniNvegp6C41yC9f4FyCUsKwfeusQIpXv6GvuTazyhHRykFu Ormm01Hy6DXxxM1kgX1a17RQ/Rj0lKJMwt3y5cklHMSURT9ID9m7Pznu9uDnRSFoVCjq o+KFnu9bVqDHcjvdVH20vFIHY4GpICyw+np5BCGnaaQcdCOpbJ68ZGeteRA7DCN9ttZA dncQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LUdyyOq3AV9hQKPqM4MkK9JMEAG65x0BoSsVBE+ksKA=; b=eClE0Xj1znDfQtFQvzwif+LU/3BU3wD8wEUfc02CS8DVwVx6ucfDvDLeDqbKUejdHe 2w0uBOGxrsFpGLF53DkC4QCkB6+v+/IzmqWfZHXvchbJM4e2CH1SdimVeGtaL2KxMrNT TMNUKbYqALDtW4V2yCK06NVybCDDgY+V5iyE4AlvcpiJuxuljLDRHcQs9aPjHvyLEaO6 HG6qPfMjGadafHJcsxUzs7Jgy6KSFaPUcGrk6tkAFUPtUig9UNB7T4n6rYiq3pYpqTbM KtsR4iAn3t2hHMFaFGRKNyqWszNztdULpkYTny+p/NGVJSL5NuRKi6dZgHAdUzQ88Zm+ IJVg==
X-Gm-Message-State: ALQs6tAWbPgy33CibpGCNSHgV0cFtSIdldK+2Vl5l4UeKgHR0FLv8FPk 5X2Qx2YTlsw3PGQmuBSQ0XpiVvDqe3y7kJT4zahu3w==
X-Google-Smtp-Source: AIpwx4+UboDSy5Svs3ltv3fOJnBnMKb6k/LQ9xaBHYuHvtdEd2kDA7Xn3uKlrrmYAfL/Q+UDVQFwJwhCLwkQwQEhtNc=
X-Received: by 2002:aca:df44:: with SMTP id w65-v6mr13704751oig.155.1523880798344; Mon, 16 Apr 2018 05:13:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.201.90.67 with HTTP; Mon, 16 Apr 2018 05:13:17 -0700 (PDT)
In-Reply-To: <209F0EB5-AC41-4D00-8FE6-755802946061@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>
From: Richard Barnes <rlb@ipv.sx>
Date: Mon, 16 Apr 2018 08:13:17 -0400
Message-ID: <CAL02cgTOOVXUXmvoE4JK97i8EeYnHevk4V9ecTepGLcB1YA-2w@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
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>
Content-Type: multipart/alternative; boundary="000000000000aa6b850569f62504"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/MSaivyuNYLOgLuiE0l7g2yPpYmo>
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 12:13:21 -0000

On Sun, Apr 15, 2018 at 3:27 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:

>
> > On Apr 15, 2018, at 2:04 PM, Russ White <russ@riw.us> wrote:
> >
> >
> >> As Richard said, the headline issue for outsiders like me is BGP
> hijacking,
> >> whether as a mean to hijack addresses and inject spam, or as a way to
> >
> > This is more about documenting how routing folks should build their
> security considerations sections to reduce the friction between the
> security area and the routing area. A much more prosaic situation, I
> know... 😊
>
> ^This.
>
>
> >
> > If you'd like to chat about the BGP hijack problem, ping me. It's not
> something I'm interested in trying to "solve" in the context of the IETF
> any longer, for various reasons.
>
> Right.  Please save this bit of ocean boiling for elsewhere. Like over
> beer.
>

Part of the problem here is that the routing community seems to regard
these issues as separate.

Security analysis happens in the context of a threat model -- what is the
valuable thing you're protecting, and what are you protecting it from?  If
you want to say you're talking about routing security, you need to either
address the whole spectrum of threats (not just, say, local threats due to
poorly protected transport), or have some plausible story for why certain
threats should be out of scope.  What Christian and I are saying is that
BGP manipulation is an active, major threat to the Internet, so it seems
odd to us to rule it out of scope.

"Ocean boiling" is part of the IETF's job description.  We made the ocean,
and if it's the wrong temperature, it's our fault.

And it's not impossible.  HTTPS usage has gone from <30% to >70% in less
than five years [1].  Even IPv6 is in the range of 20% now [2].

--Richard


[1] https://letsencrypt.org/stats/
[2] https://www.google.com/intl/en/ipv6/statistics.html