Re: [secdir] New Routing Area Security Design Team

Richard Barnes <rlb@ipv.sx> Sun, 22 April 2018 22:46 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 D2D3E1200FC for <secdir@ietfa.amsl.com>; Sun, 22 Apr 2018 15:46:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.395
X-Spam-Level:
X-Spam-Status: No, score=-0.395 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_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_RHS_DOB=1.514] autolearn=no 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 uH68i_p2MIn3 for <secdir@ietfa.amsl.com>; Sun, 22 Apr 2018 15:46:18 -0700 (PDT)
Received: from mail-ot0-x241.google.com (mail-ot0-x241.google.com [IPv6:2607:f8b0:4003:c0f::241]) (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 B4D40126FDC for <secdir@ietf.org>; Sun, 22 Apr 2018 15:46:18 -0700 (PDT)
Received: by mail-ot0-x241.google.com with SMTP id a14-v6so15215149otf.6 for <secdir@ietf.org>; Sun, 22 Apr 2018 15:46:18 -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=Yg9BMSLuWRJUJVsWRl+0kyvS2swtFXzf9PyD/38eIqM=; b=bBi7P3zMLIl4hxM/VT7GvdEHtkl5cL8i5GSfccQvvZFE8oIgnqEIS98Xae4FJquFT+ rNnEQFh/xXTGuPzzYMQU6WSFCrrxwEH/TnFPiFfcm3cKz1FT+v4TQuyv7P09gbKtZqTf CkHFLo42qyf6+JJ29K0ocVVGyp4w/q0bklCd+3tkyPoAscsqAjesBo2qfCxKSsO6PiR6 HMNMYuqzCESvJh57UaLmeieDl5nJ593l1LYBDHMoKzN7EGe1qln0uewyN2E7TvIo6iZg MgJVT9PDzAHFiIkyeFrzmB42w6GdW2uObcunhPmendeaXeTJ6NWa3iHE58WA/4Yaq8ph Fjsg==
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=Yg9BMSLuWRJUJVsWRl+0kyvS2swtFXzf9PyD/38eIqM=; b=P0wF+1e995XFNJgvkoLvzESsc64Q380pThJIbaGrlqulRt+A7JV56C1uiktYxTgxJ5 d9LncdtQeXq1ATZI3uFELJav8zAzRkjOMK5jt/jDXBQuAcyTn0Ty+7ZPd4Bok3Jq1UW7 gTdojt4wod7ZmYcIf7bznDGFU+MwSPjCZNSfw3inhA4W8gN2XSUvxRPXujAvhTfARwiB Nukish1JMZRWgwoFil2ktOAfN2RetxS3BEXdbZMhYw/4/6od1GSwIN8Nz4mjhBF8dWEk UJnS6iHKEUpOHIyPadc9FIkmw2RYMDs4gCmZYeyA7SGWY/ilnkSOvkmAP9wluSwwlWto ds+w==
X-Gm-Message-State: ALQs6tD8eE7K0aSFd5TpokovMU5iZHqdRC3ttht14LzHAUTULUlw6Uyd Z01ZZDN4N2QnyMQ8YqphVZ821ULfCAsg5prhcCWPvw==
X-Google-Smtp-Source: AIpwx4/CRFeKPB1tY2aCoZKUDzJb6qLA1anB8KPZIG753N/x2gh+/qXL7Lrg0dK2Td+7fM8c/BTtLrQxrdsqHpacXyo=
X-Received: by 2002:a9d:27a6:: with SMTP id c35-v6mr11998220otb.271.1524437177784; Sun, 22 Apr 2018 15:46:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.201.93.90 with HTTP; Sun, 22 Apr 2018 15:46:17 -0700 (PDT)
In-Reply-To: <CABBF7D4-2B9B-4403-9C00-63C76906E631@sn3rd.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>
From: Richard Barnes <rlb@ipv.sx>
Date: Sun, 22 Apr 2018 18:46:17 -0400
Message-ID: <CAL02cgSR_q4VaJTNZHb-fReU0AxVYsO1eNHDtVGUtd2jmzmfnA@mail.gmail.com>
To: Sean Turner <sean@sn3rd.com>
Cc: Jeffrey Haas <jhaas@pfrc.org>, 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-Type: multipart/alternative; boundary="00000000000076ee55056a77b0b2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/hH1bhilVg3AZV9WUg5SizmJM-ZI>
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:46:21 -0000

On Fri, Apr 20, 2018 at 10:36 PM, Sean Turner <sean@sn3rd.com> wrote:

> Having tried to help* the last time the routing and security got together,
> I can’t help but suggest that with this:
>
> > On Apr 15, 2018, at 15:27, 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.
>
> and this:
>
> > 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
>

LIPSTIC - Limited Improvements to Secure Transports for the Internet
Control plane

We're not going to make this pig any less ugly, but we will apply some ...

--Richard



>
> 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?
>
> spt
>
> * for some value of help.