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

Joe Touch <touch@strayalpha.com> Sun, 25 November 2018 15:53 UTC

Return-Path: <touch@strayalpha.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 6E4E312E043; Sun, 25 Nov 2018 07:53:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level:
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 kdNWq6e51UYC; Sun, 25 Nov 2018 07:53:53 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A6D128766; Sun, 25 Nov 2018 07:53:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SlIthBMQn84W1Lzko9ITzfs9m96qw9dgqr3YzzNrmlE=; b=TNoYenUm17oc08SGvbHyl5UfD 5oZnQMygt4CFrMIeGcIo7GT+f3Or4cVmMlyPASw0WnnIjlbPCdTMYkRNm6vMvTS7zGKkT70zBxeCH eol0ByqoQTL7yqa3Q5Sv3SWsOw0EjTcWFAX+5w5bgWyAIWXeC0vbrXNSE8gBfRmTfFnuPUMDWRpPc 48sDCr9hJQHzcIKNeg7mPzJwyVU/9m8pXn73y3qKiM/mkXAtnzy5yXlKepDylk65IQcdDeS/1wfFv tfCIvGNXagF7JGrZkaZYM7D3nNer0Wb7ZqKyI0o3EfX13P6j9MT4eMzFpmm4hX+YfLWJy7NTGe8Vj pgqu6Eg7g==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:58013 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <touch@strayalpha.com>) id 1gQwjA-001rdL-7b; Sun, 25 Nov 2018 10:53:47 -0500
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <0f56c25d-7ac7-e534-4e2c-cc09f5154e77@foobar.org>
Date: Sun, 25 Nov 2018 07:53:43 -0800
Cc: OPSEC <opsec@ietf.org>, ietf <ietf@ietf.org>, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org, tsv-art <tsv-art@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <28EDE667-457E-4AED-8480-F27ECAA8E985@strayalpha.com>
References: <154300282321.9639.11604402305352742547@ietfa.amsl.com> <C4886ABA-3BBE-46AE-B2D9-9A6836D7A8BB@strayalpha.com> <2c28d4ac-87de-bcaf-54e8-4e745235c800@gmail.com> <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>
To: Nick Hilliard <nick@foobar.org>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-0.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/3NIzkfRHvTcNp3gXlf-381QssRs>
Subject: Re: [Tsv-art] 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: Sun, 25 Nov 2018 15:53:56 -0000

A reasoned discussion of the pros and cons would be useful.

What we have is the perspective, often heavily represented by vendors and operators, of the driving reality that:

a) implementing extended features is an attack on profits
b) properly configuring and monitoring extended features is an attack on effort

A reasoned argument would be useful. That is not what has been repeatedly presented, IMO.

Joe

> On Nov 25, 2018, at 4:59 AM, Nick Hilliard <nick@foobar.org> wrote:
> 
> Joe Touch wrote on 25/11/2018 06:24:
>> The reality is that standards are not followed, agreed. That does not
>> imply that we need to relax those standards - instead, it can be
>> reason to fix broken devices.
>> Working at the level of the most broken device is no way to run a
>> production Internet.
>> And claiming that doing so is appropriate for security reasons is
>> just as broken, as it always has been.
> Joe,
> 
> another point of view would be that operator feedback should be welcomed because sometimes protocols are found to be difficult to implement fully, or when implemented fully cause unforeseen consequences.  EHs are a good example of this.  When originally conceived - for the best of intentions - the spec was sufficiently loose that they were not just unimplementable from a practical point of view, but the spec was open to protocol level security problems.  RFC7112 describes some issues relating to EHs, but there are plenty of other examples.
> 
> How, where and when to filter EH packets creates a bind, no doubt about it. Some EHs are intrinsically troublesome (e.g. anything with hbh processing requirements); others can be processed without issues.  The IETF can choose to ignore this problem or get involved and have some influence about what might constitute best practice.  If this happens, vendors might even fix some of their silicon.  Declaring that the problem exists only on one side won't make the Internet better.
> 
> Nick
> 
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art