Re: [OPSEC] Architectural implications of EH / filtering (was: draft-ietf-opsec-ipv6-eh-filtering)

Warren Kumari <> Wed, 12 December 2018 21:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D37B1312DB for <>; Wed, 12 Dec 2018 13:55:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.358
X-Spam-Status: No, score=-3.358 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7JZaqfO3pBgi for <>; Wed, 12 Dec 2018 13:55:25 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B77EA1312E2 for <>; Wed, 12 Dec 2018 13:55:24 -0800 (PST)
Received: by with SMTP id v13so19227153wrw.5 for <>; Wed, 12 Dec 2018 13:55:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AGTF/RWJlEPV8t2Bbt5Guk+RDWg9bXqyJey3SHLpnEA=; b=CZpos+TrtEnF3kmMypVJLLz9xZmR48G5yCcojvfnl9ZY1i9E69cOrTynwjVTeOTl65 0q55Dy/N8D+dZoTdJem8B6jXof+kgFzjc0MjufAsgPYSjR+BInu049pwhal1xObBAn9p 8Xwd40mgk5zsWXINv5rjaqdxw6XVYCXrXdnpUfYL7I+QCR4Hl9s7+LeZxaRd/IekR+DU Vrumi/ijNK2W9bpO55Kk5u+74nZ16uAVun6J+GU1MsV8pUYd7ZuDZnrJpHV2NW8I+Esz e+NLnLZVcUTSzDqB2qTxhiYSsAR5VcEJ1H6d8SZy/L/CCMjOysm13Fx61Rf+H2lQBe3E ZEPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AGTF/RWJlEPV8t2Bbt5Guk+RDWg9bXqyJey3SHLpnEA=; b=FhoWQQ6x8pMS0skY+G0vio7U04YNiwV9GBxyLBZbFoNUJTKO5N+KvRBlW/07FQ/r2r 0AfWjAIVfnOvqQg+AkV2Ffo3SUxKWNdMtEueam3AfFiW1/+6UwA9QwY8KOcxn3hSRAnu 5X5uc0mBsTERqY9ic54rM6ouCRXviGYSmE8/BKnvjBWvTZI3VVVWE+zBg22Xe836XL9r P87Ds/gnDOLy04gSmlVFX61/G4OIfeySF0oZ4Ka7zHEpcq0RvsoTC03Nv2J1zVkK4CuH IMUcX4ClMxPpi6aOlr/onE12i7vS0Vc8mKLbQbNHvGv1yaAHTTa3rHzjAWouspTrf4+D RlMA==
X-Gm-Message-State: AA+aEWaI574kKa8nreOq6T3Nr8RmzKPKsm9g76sVJhbHCVDl8uN1ljzJ Rv5F8CnAUKrja737/9E2IWvvlOZCDhjZovUzx/dBfg==
X-Google-Smtp-Source: AFSGD/UrzwCAPXeNbKOdn2pVc+BH3qJySHLqHDr4JmiBedLxw9FpaQ+m4BJkwW5mVdvwwwIIg5l4JMMZtgu2N/yNHOI=
X-Received: by 2002:adf:f0c5:: with SMTP id x5mr17949458wro.77.1544651722743; Wed, 12 Dec 2018 13:55:22 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Warren Kumari <>
Date: Wed, 12 Dec 2018 16:54:46 -0500
Message-ID: <>
To: Ole Troan <>
Cc: IETF Discuss <>, opsec wg mailing list <>,,
Content-Type: multipart/alternative; boundary="0000000000003c8090057cda41ae"
Archived-At: <>
Subject: Re: [OPSEC] Architectural implications of EH / filtering (was: draft-ietf-opsec-ipv6-eh-filtering)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: opsec wg mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Dec 2018 21:55:28 -0000

On Wed, Dec 12, 2018 at 3:32 AM Ole Troan <> wrote:

> Warren,
> Thank you for your note.
> > On 12 Dec 2018, at 00:58, Warren Kumari <> wrote:
> >
> > The IETF LC thread on the document, and the TSVART review (and
> corresponding thread) both generated useful, and actionable comments, and
> I've asked the authors to go through them carefully and address them --
> these fall into the "on the document" category. I think that once these
> have been done, the document itself will be in acceptable shape to proceed
> (but keep reading!)
> How do I interpret this? Are you saying you think there is IETF consensus
> to publish?

Yes, probably.

The discussions **on the draft itself** (and not the larger, philosophical
discussions on operations vs architecture / what is actually implemented vs
what routers should be able to do) looks like (after the editor makes the
agreed to changes) good enough rough consensus for me to progress it to
IESG evaluation.

It is entirely possible that it will not survive that step / will be sent
back to the WG / another IETF LC on the revised document will be called for
/ it will be munged beyond recognition at this point...


> Cheers,
> Ole

I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of