IETF Logo Mail Archive

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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 06 December 2018 00:05 UTC

Return-Path: <brian.e.carpenter@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 5DC77130E73; Wed, 5 Dec 2018 16:05:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 lmlmKbxmmIeH; Wed, 5 Dec 2018 16:05:27 -0800 (PST)
Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (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 75F13130E51; Wed, 5 Dec 2018 16:05:27 -0800 (PST)
Received: by mail-pg1-x543.google.com with SMTP id s198so9783460pgs.2; Wed, 05 Dec 2018 16:05:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=mzW91bh7J8Yg9VKRfUgXWwe8dWciIeDLbBJarYaDyw4=; b=vgWxlCkJ2WyONLxszIUG52KFFuTFFbrmi8xPwJ1HP25iJQA/cR4khXj6wLvfqIt0hS 0pLYpO2ZOg8n35zDqr1r8+Okghd6tNwdowrJJGk/+mDaG3uT7cbMGJS7KbdV1ZXp4Z/w RzjW+rBPF3OV84qCzXnhz5nTWYkoqldZk9rmPcvbYDgVU0lZBnVGNc4FxaxuKS3peX0I kLcmZeGxVF95h8/weGWD0EI8JiFwjXoqqU4608m5qCC+Z0AzUeRjI3bL+Xzxe5Bxl3KS NJ+oOqhSTwVAD0C40sJBi7eH/HxFeUTMKqZf3pMs2fTJWUvhIcqgFgyGoMHN0TMhe17U kkGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mzW91bh7J8Yg9VKRfUgXWwe8dWciIeDLbBJarYaDyw4=; b=gzcYFruj216tMDkV5MPluemX/YQr9NuNoi1upDOaFVLaOQAqpWYwSDjykIM0oS+1Km fF8hfROr7S8is+nG21kpwOzeeKIjZmV5z+9G8oAwn7IYIWd6ZsVkxuTPw5cxHFIsk54J PYX2Pf1JBnVEabfXOI19SHLIlwlNrfZRdCmY9mPQA7Cqr4BW2Z/jH1wr3Qh0aWHAYW66 JDRH5seDHUhlbmOOTvlrh6fenlKPnXl8EbrZEkyLKEgw+KIMFBeCRnPf/799yKoYbEof 46vJDAh5NCnUs1+z2TYbKYsg0QGR3wCCIzulXr21UU/w6jQIsq5yA2sCQkx4gctEsYHR k3sQ==
X-Gm-Message-State: AA+aEWYY/MOFoB75bzKKrFEfUQp9pP6HNQx2H634VnUb414KOVCMfxdP hITYbA7paGTbZGieZejiW+2SWRgXbvA=
X-Google-Smtp-Source: AFSGD/Ur50KHsEY9jPj48J+CCKGEdherJU7r3jOh2a6CeEIcjB1IR3ZqSrKpM2O9/2SEgQxqIOowmw==
X-Received: by 2002:a63:4745:: with SMTP id w5mr22783380pgk.377.1544054726695; Wed, 05 Dec 2018 16:05:26 -0800 (PST)
Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id o8sm52262561pfa.42.2018.12.05.16.05.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Dec 2018 16:05:25 -0800 (PST)
To: Joe Touch <touch@strayalpha.com>
Cc: Christopher Morrow <morrowc.lists@gmail.com>, ietf <ietf@ietf.org>, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, opsec wg mailing list <opsec@ietf.org>, tsv-art@ietf.org
References: <977CA53D-7F72-4443-9DE2-F75F7A7C1569@strayalpha.com> <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.gma il.com> <728C6048-896E-4B12-B80B-2091D7373D16@strayalpha.com> <8a676a4a-c76d-9fa5-ce79-534a14cf0511@gmail.com> <2386B45D-8AEE-4C95-BB00-A5A2ABF63F8A@strayalpha.com> <e5198c02-ebc6-ee3e-96cb-fd2831164f41@gmail.com> <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <6c071ce7-609b-fcf2-8977-9159afece9ec@gmail.com>
Date: Thu, 06 Dec 2018 13:05:19 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2
MIME-Version: 1.0
In-Reply-To: <02AD0268-BFB8-4CA2-8985-08AFE6013ABB@strayalpha.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/SFf-y9SYe8dFEfEcPvAu9KQPqU0>
Subject: Re: [Tsv-art] HbH flags [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: Thu, 06 Dec 2018 00:05:30 -0000

On 2018-12-06 11:50, Joe Touch wrote:
> 
> 
>> On Dec 5, 2018, at 12:04 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>
>>> On 2018-12-06 01:16, Joe Touch wrote:
>>>
>>>
>>> On Dec 4, 2018, at 8:46 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>>
>>>>> Nobody deprecated the flags that require HBH options to be processed or dropped if not supported. 
>>>>
>>>> Intentionally. If a forwarding node is transparent to HbH options,
>>>> it is not looking at those flags. If it is looking at HbH options,
>>>> it will obey those flags. Why is that a problem?
>>>
>>> What exactly does ‘transparent to HbH options mean’ if not ‘not supported’?
>>
>> It means a forwarding node that uses the exception added by RFC7045 and simply
>> doesn't even look for an HbH header. The flag bits are invisible and irrelevant
>> to such a node. The flag bits apply as defined for a forwarding node that *does*
>> process HbH options, so they certainly should not be deprecated
> 
> Do why bother with “drop if not supported” if not supported can mean silently skipped over?

Ah. I assume that you are not referring to RFC7045 + RFC8200 (the standards)
but to https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#section-3.4.1.5 , which is quite nuanced. All I can say is that *if* we are going to issue guidance for security-based filtering of HbH headers, that advice seems realistic. It does include this:
   ...  Finally, when
   packets containing a HBH Options EH are processed in the slow-path,
   and the underlying platform does not have any mitigation options
   available for attacks based on these packets, we recommend that such
   platforms discard packets containing IPv6 HBH Options EHs.
Frankly I don't think you'd find any operational security practitioner who disagrees with this.

Whether we *should* issue guidance for security-based filtering of HbH headers is a broader question. All I would say is that if we don't, then either somebody else will, or default-deny will remain as the most common practice.

  Brian
 
> Or the other variants?
> 
> They’re now meaningless but required to support. You don’t see the contradiction?
> 
> 
>>
>>   Brian
>>
>>>
>>> In that case, the flags have exactly no meaning anywhere. But they’re not deprecated.
>>>
>>> That makes no sense at all.
>>>
>>> Joe
>>> .
>>>
>>
> 
>

v2.23.0 | Report a Bug | By Email