Re: [Tsv-art] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06]

Eric Rescorla <ekr@rtfm.com> Sat, 08 December 2018 05:50 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8888612D4ED for <tsv-art@ietfa.amsl.com>; Fri, 7 Dec 2018 21:50:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.356
X-Spam-Level:
X-Spam-Status: No, score=-3.356 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MARKETING_PARTNERS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 wRz_hcizVJUZ for <tsv-art@ietfa.amsl.com>; Fri, 7 Dec 2018 21:50:01 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 04C46131113 for <tsv-art@ietf.org>; Fri, 7 Dec 2018 21:49:57 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id t9-v6so5326916ljh.6 for <tsv-art@ietf.org>; Fri, 07 Dec 2018 21:49:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1lRroBboWIhZL52lUvt/gbQSoqZlLlVXHvAgKenCR8U=; b=uwMBdQR+XY/o2rWSjvN3iL5L8HKt67djPSrzrwunCZVFtMexD9ixpoRRGTazpThADg iG3B70AGqTMA1TBZhX+yIiCFbjZ6U9D7lobFYLFdudo+up0yC+Zjn/TiSo2EZ38hebE/ eTkBCRFMPRofQdOcN4a31gmSDPrR2/1TJOezCV9MEjCkb8OoLu1/+37U16yBxw4l/yN6 /gSpGXui6uHGWKgo+KZbHPTudgzv2bd2PUfxmPZliIEqTU6Xi58QPKjtMP53gQh6SViU xsrZD2kkP6NzsvG7G6/zSx4dHPj3DCRSBxRpisSlrTfHZFdgew99NO+/0YORaLIo5Tmw WBSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1lRroBboWIhZL52lUvt/gbQSoqZlLlVXHvAgKenCR8U=; b=TNOqW5n/NmlFhtH40wPi0roW6w6ceTUTVttsTfwpYWeNdLDSmHWZ2MB3XVARfDslr7 zPIXIdIYwEgQdHEoltNqQXZqSjbUCcGsUmJpMvUQ7QfIbNfTvCn4kVduCTyObcnqg9gr QfYErKTrEb2aOI3XASOzJASpW3zeyKi4M8ydgugoZbbV121CcAcWlQkwUPJ235w1BX9O qbmZ3nsUbOvJBbLLdunLiRuJAd8ZxdO8rBTdr98KWZIuN3hijYuCIa/mWuVllPj7+w3v iS/ruN1cEPl7AfG9DB1zEjfSIToacDu01S6rRN1zn6r7JJ2wmLvqwgWOLowrmUpdWAGT zwyw==
X-Gm-Message-State: AA+aEWYcNU+h/Jiy+ddaDXpwM4nExyMME1dvAENemhDypFp/wOaF8NZz JpUSGZGbFbJHAjjgCBZpeZM7K0d9VLD+qQ1AxrBEmA==
X-Google-Smtp-Source: AFSGD/XwRYhPzUreEyffD8r4WltYKapPNh4bhQDMAizWR2tvTHYoL/YIoRyWbvxbnv+XKuLdEauKcrG6ltJFYtrELa0=
X-Received: by 2002:a2e:5418:: with SMTP id i24-v6mr3060863ljb.51.1544248195141; Fri, 07 Dec 2018 21:49:55 -0800 (PST)
MIME-Version: 1.0
References: <CACL_3VGeJPzDhS0RVAvpQs9W8b4EODft-qJRwBD6Xxm+X6BZ6A@mail.gmail.com> <CAL9jLabK0bZz2nki=oFNHT0OrpVAB8pw7emAj2BtkHRCzkfmqQ@mail.gmail.com> <cf64abbf-e447-71e3-b983-4e525cc139aa@gmail.com> <CAL9jLaYMRDGFa7Qzj4ukRV1FPbJM40qbuZ34SYxoA30Z+h3EWw@mail.gmail.com> <20181205085227.GG1543@Space.Net> <9ba948f9-f286-1016-2dbd-f7056a15e744@gmail.com> <74d89efc-bfba-6e54-ebb2-d688e45b139f@gmail.com> <20181206125726.GG1543@Space.Net> <d078ea0f-3c2c-f782-4c1a-b54c463b48ce@gmail.com> <CAKKJt-eNCeV4hS=v99NGAYFkkmLdSO5Cp9gk2ojdbZ5vrU7img@mail.gmail.com> <90130407-2B6E-491A-AB9B-BEBB45604D50@puck.nether.net> <CABcZeBNB3scdEm0aF99KeD3F=JvqCU1yaxL1cepFhnE+dg=0Wg@mail.gmail.com> <CAL9jLaYiMbMfyLK8b97TEqNcJVaQzfyC=HZvo4F01b3KZaYdVg@mail.gmail.com> <B60C8071-9577-4935-A260-FAE0EF80AFCF@puck.nether.net> <CABcZeBOZ4bQoT=FPa0vHfd9UZ8siqhh7w88xurNOqNpNyF_S=g@mail.gmail.com> <BDEEBADE-EBC7-4BB6-9FB7-3B02EB57AEBB@puck.nether.net>
In-Reply-To: <BDEEBADE-EBC7-4BB6-9FB7-3B02EB57AEBB@puck.nether.net>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 07 Dec 2018 21:49:15 -0800
Message-ID: <CABcZeBNf3nKcNPnUkZb1gmDHZ2GHDMbm_cdgnt5ojTyRhVWNMA@mail.gmail.com>
To: Jared Mauch <jared@puck.nether.net>
Cc: morrowc.lists@gmail.com, IETF discussion list <ietf@ietf.org>, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, heard@pobox.com, opsec@ietf.org, tsv-art@ietf.org, Gert Doering <gert@space.net>
Content-Type: multipart/alternative; boundary="0000000000001df7f0057c7c4d96"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/4Fnk5aIrmnh3rhE9wpcAdfle8F0>
Subject: Re: [Tsv-art] game over, EH [Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06]
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Dec 2018 05:50:03 -0000

On Fri, Dec 7, 2018 at 1:17 PM Jared Mauch <jared@puck.nether.net> wrote:

>
>
> > On Dec 7, 2018, at 3:59 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> >
> >
> > On Fri, Dec 7, 2018 at 12:46 PM Jared Mauch <jared@puck.nether.net>
> wrote:
> >
> >
> > > On Dec 7, 2018, at 12:10 AM, Christopher Morrow <
> morrowc.lists@gmail.com> wrote:
> > >
> > >
> > >
> > > On Thu, Dec 6, 2018 at 5:41 PM Eric Rescorla <ekr@rtfm.com> wrote:
> > >
> > > routing area (key agility, a stronger algorithm than MD5). And of
> course TCP-AO doesn't attempt to provide privacy. Perhaps you can elaborate
> on what you're referring to here?
> > >
> > >
> > > "TCP-AO is a lie, there is zero deployable code anywhere that supports
> it"
> > >
> > > was that the gist of his comment?
> > > it'd be the whole of mine... because honestly it's the truth.
> >
> > I had written out a series of concerns around the requirements operators
> have.. I can’t find the paper around my office right now I wrote them on,
> but the went roughly like this:
> >
> > 1) We have long-lived TCP sessions, measured in years.  (Implied: many
> of the transport people really prefer stable routes without
> flapping/jitter/reordering from us)
> > 2) We use protocols that are stable as a result as transports
> > 3) Security area does review and says “why is MD5 still a thing” without
> considering #2 and #1 above
> > 4) When doing routing things like an iBGP mesh, key rotation can be
> complex in a multivendor environment when the catastrophic failure of the
> network substrate is the consequence of a software bug
> > 5) If these keys (md5) are in use, they’re not rotated because we got
> that support much later than the ability to set/rotate them and
> coordination with a network partner to rotate them is feasible but reaches
> operational impossibility.
> > 6) We need protection from tampering with the transport, not encryption
> of the transport.  You will know where the routes go because I assume
> you’ve used a tool like traceroute before.
> >
> > I think most of these points are reasonable (I'd quibble about #3) but
> they're not very actionable.
> >
> > If you're position is that TCP-MD5 is all you need (and maybe not even
> that) then OK.
>
> It has problems, I’d like something “better” and a path to get to that
> better thing.  I just built a Greenfield network and we used some better
> methods than my prior employer was able to use.  We often get technology
> lock-in when we use things for “security” purposes.
>
> > If what you want is some protocol with other, different, functions, then
> you're going to need to be a lot clearer about what it is you *do* want,
> not just what you *don't* want.
>
> I’m speaking about the operator challenges we have.  I don’t have a draft
> that’s getting caught up in sec-dir review because it still uses TCP-MD5
> because there are no TCP-AO or other implementations, or a migration path
> to them.
>

Well, drafts don't get stuck in sec-dir review, because those reviews are
non-blocking. And I'm pretty sure that neither Ben or I are holding
discusses on any such drafts. If so, can you list them, please?



> What I am is an operator that has experience in running a network, trying
> to be minimalist in my responses to the badness, and keep it up so the
> higher protocols can do their thing.  When it gets problematic is when I
> can’t differentiate something good from something bad as easily and people
> decide to shift that line.  I’m warning you where the guard rails are, they
> may get moved.
>
> This entire draft I see in the subject/cc line is part of that, here’s
> what operators are doing.  EH’s are a cool idea, but they are also a
> security risk in that they may end up in the punt path or significantly
> impact performance of the forwarding plane in a way that could cause the
> networking substrate to cease to function as desired.  These are things
> operators will work hard to protect to ensure it’s working.  The network
> has limits and just because it works in some hardware doesn’t mean it will
> work in it all.
>

I have no position on IPv6 EHs.

-Ekr


> We are stuck today in many cases with whatever we get in a BCM Chipset and
> that doesn’t appear to be changing (although I hope it does change, and
> there continue to be options in the market).
>
> There are many protocols that need to be cleaned up, just like most people
> stopped running chargen on their routers after it was used as an attack
> vector.  The same was done with changing the defaults around “ip
> directed-broadcast” behavior.  Expecting intermediate network elements to
> honor requests in EH’s is not likely to change.
>
> - Jared
>
>
>
>