Re: [Tsv-art] [OPSEC] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06

Christopher Morrow <morrowc.lists@gmail.com> Wed, 05 December 2018 05:37 UTC

Return-Path: <christopher.morrow@gmail.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 1C604128CFD; Tue, 4 Dec 2018 21:37:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 hpkegXVoYI9p; Tue, 4 Dec 2018 21:37:40 -0800 (PST)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 23E2712D4E9; Tue, 4 Dec 2018 21:37:40 -0800 (PST)
Received: by mail-io1-xd32.google.com with SMTP id f10so9882198iop.10; Tue, 04 Dec 2018 21:37:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sf3lJ62CgSlnmj1arx3aSb5oxC0OeSc2hvZmErwsaJk=; b=NcNnEpjXGxYGGHLu4ufNfTV/iZkPW1gOfI1wOLYT+slY+wbYChuc6/+a1LYN0KdGXV 0+0MAJIqW6+JKsoeUG48IStc1NBl2O66XwnCUmLCzdfeC4UyOqTdVTzmsdWSTGaSGPKb 4ldD60cBJy8e0HS/aGMEQTK9cToT1cvj74BXz+wgISo3DbnlkFInMCxIEuokMZGyO6/T k0OK78Rdld7C74BlcVmHfJbXIyeQFY5hSmaQkdqZDTJnj8/9PTs7CVpfoL/7LGuwdsQE J4BV2fgwk2mJIdg9ecaNbBeSbSDemnUogNcNFqagy+JY5yy3yXNOp8ymNQGOHn5eAu0C 2xKg==
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=sf3lJ62CgSlnmj1arx3aSb5oxC0OeSc2hvZmErwsaJk=; b=jrSjAnjfYH2BHsHBYR8APcj+OaXTj9+hzufzOd8atvGibGlphuzQu3jvQ9tJhapxwz kD28+ni4Me8bpS3DkmRIew+JAGPPie090vMbqXFOlgDauiJqLcvJ4snoj3rypj880zr/ i+vFyPgTqw/BXRVBCWxi6CacPzYH5H4UkKIZeQBdralPm1e7nEc9jf0TKwjxJDNW4N9h OoAwmzzdFGt6oDzlMv2npRhEyztSZ78RdRhP9LvNyoOLGrxlJRE7rEzckqBN3yGk+svs h6YKVAfc7MBvkDOpYodEJy9W0by7xnT4JzdTfEu0kEN7OAh5ZtH/qwVZlgXjWqytHuoS SjoQ==
X-Gm-Message-State: AA+aEWZddpupavrkccNnFDaExfTbv6Gxdpp63QgKpuKGYcGRNACbAOxy SaZ494Fw2PiadJ5qfW2AWCEdz68cXTQTsAFmsls=
X-Google-Smtp-Source: AFSGD/X8+Whpag6Soo0fKTG6rBHq/5FYPdnuCaq2EZCrx4UKwRYed26hrODhOPH3S+WhfB+yfsbl9tYzjR10STZ3p7k=
X-Received: by 2002:a5d:844d:: with SMTP id w13mr11300319ior.17.1543988259144; Tue, 04 Dec 2018 21:37:39 -0800 (PST)
MIME-Version: 1.0
References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <d6deb7af-99dd-9013-2722-8ebbe00c0b37@si6networks.com> <1CB13135-D87A-4100-8668-D761058E1388@strayalpha.com> <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org> <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com> <6bd1ec94-f420-1f4c-9254-941814704dbb@gmail.com> <6be84ccf-9a72-2694-e19d-fa19043a0cb1@huitema.net> <4C249487-BD58-41BB-B8B6-081323E29F6C@strayalpha.com> <20181126075746.GO72840@Space.Net> <6C50775C-EB67-4236-93B8-DF0259E04167@strayalpha.com> <20181126175336.GW72840@Space.Net> <c959d8cb6f6a04a8da8318cfa89da341@strayalpha.com> <2425355d-e7cc-69dd-5b5d-78966056fea7@foobar.org> <C4D47788-0F3D-4512-A4E3-11F3E6EC230B@strayalpha.com> <8d3d3b05-ecc3-ad54-cb86-ffe6dc4b4f16@gmail.com> <C929A8B9-D65C-4EF7-9707-2238AE389BE3@strayalpha.com> <CAL9jLaY4h75KK4Bh-kZC6-5fJupaNdUfm1gK2Dg99jBntMCEyQ@mail.gmail.com> <C47149DC-CAF2-449F-8E18-A0572BBF4746@strayalpha.com> <CAL9jLaYfysKm7qrG=+jq7zV=5ODnSX-tAhBAiTU7SzYF-YmcGw@mail.gmail.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com>
In-Reply-To: <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
Date: Wed, 05 Dec 2018 00:37:25 -0500
Message-ID: <CAL9jLaYHVdHr+rVoWeNtXTXgLxbTaX8V9gn3424tvsLW60Kvow@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>
Cc: ietf <ietf@ietf.org>, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, Nick Hilliard <nick@foobar.org>, opsec wg mailing list <opsec@ietf.org>, tsv-art@ietf.org, Stewart Bryant <stewart.bryant@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000b94bd7057c3fc794"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/ngdszv90ekarKZ6hRSTYikhw-6A>
Subject: Re: [Tsv-art] [OPSEC] 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: Wed, 05 Dec 2018 05:37:42 -0000

On Tue, Dec 4, 2018 at 11:32 PM Joe Touch <touch@strayalpha.com> wrote:

>
>
> On Dec 4, 2018, at 8:11 PM, Christopher Morrow <morrowc.lists@gmail.com>
> wrote:
>
> That works only for HBH options of type 00. Others require particular
>> actions when not supported.
>>
>>
> can you expand on this some?
>
>
> Nobody deprecated the flags that require HBH options to be processed or
> dropped if not supported.
>
>
Oh, you are highlighting the difference between the 'theory' and
'practice'. ok.


> And if there is a security risk to the control plane, it is using that
> place for slow path processing without properly limiting its use of shared
> resources.
>
>
sure, that's a fine point. Doesn't actually change the state of the world
where: "If your control-plane collapses, you have an unavailability event"
which is a security problem. It's also an operational problem and likely a
cost problem :( but... maintaining availability is part of what a good isp
security group will do for the isp.


> This idea that packets processed as intended are a security risk is like
> saying big packets are a security risk to small packets. It may be a bad
> design but it doesn’t mean such packets are inherently a security risk.
>
>
it seems weird that in this case 'this is not a security problem', but
sending a packet that breaks some assumptions in the applications at the
end points and causes unexpected problems with the end point(s) (say sql
injection in a web server or breaking some ssh server through some
vulnerability) is a security problem?

Instead of rat-holing on this point though, don't you actually care that
the end points can do their work regardless of the network devices? (smart
edges, dumb core ... that sort of thing)

-chris