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

Warren Kumari <warren@kumari.net> Thu, 13 December 2018 20:23 UTC

Return-Path: <warren@kumari.net>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD85130E89 for <opsec@ietfa.amsl.com>; Thu, 13 Dec 2018 12:23:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level:
X-Spam-Status: No, score=-3.359 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] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 XRcQ20EG_oqz for <opsec@ietfa.amsl.com>; Thu, 13 Dec 2018 12:23:07 -0800 (PST)
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 0D82E130E7D for <opsec@ietf.org>; Thu, 13 Dec 2018 12:23:06 -0800 (PST)
Received: by mail-wm1-x330.google.com with SMTP id c126so3715015wmh.0 for <opsec@ietf.org>; Thu, 13 Dec 2018 12:23:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gDWsPZOUVjpDLnEHXA8Hb0GzVGubWqaBJ4+AJhOG12M=; b=otMcNx5a2GQ2PNlsisRO3QV2LJYlcJAWANCtIDeq1KQ2vXoj6vagoOnHAywgW8K6VE PLP7SO1DKIjLhm14O1YURSmI7nGwhGf90yQwCaaO2ZsYsbHfLRmC8o/TqySgMy7cbxvk FiE9zFK6ymR0FPpCO5K1cBU23AyEjhtI9nbkQMvTitXetAb8UpY7FIoWmffqJgwCtZmg WsrmiOH+YAxuqNmAJKe0AoS5r8p2cBL047L7kfKvrx0+dS9MEP8W8Sly2FR3ASG99VRh leVjkSpe3m/G2VCNiCGiGmr9q/o5IxkONkHVv/3fUC31F2oDJXMAE1qAqBv4VM65ZgaE 5nqQ==
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=gDWsPZOUVjpDLnEHXA8Hb0GzVGubWqaBJ4+AJhOG12M=; b=WJJnLOmp7lKwcOBQ0fFgVfy1p4+ycMFXBTOMaNqAyD6DKkqfRJAGltqCoqG+aV5DPb NaCqq94aQjBWWLaTae38fcMGAcEU7Nni6pRUXpI0ygY0n7wwrD0Hx9QPeQCZmT2M7lvP 8hEfbGzpjW4C22HOovsc2t4MCl5SXK2nB95C7trG7HV+8rRnNt9GWa85iiYt0TKikgtA LyncEoUNNTVhFSfqDGPFS3o8VRISc+WemCPQSmsKHHr4PBUEzjqOVSfrzq2wu21InBID YM9qlOjDQBMGaEamMh6ZlmGU5kVUE/ohCtjvTPrSWCL0gwV7boKIxEsSPX0z3JNcumLk AVag==
X-Gm-Message-State: AA+aEWa1r4j4GTkbS9hXibmZANMGulRjmL5LHAuVq1eCkbujhE3EHi1/ rGRoR6VHY1tZ5aEgTcoSA77THxn3D9sZgKZgLhelUw==
X-Google-Smtp-Source: AFSGD/VljfIglZXYcTEKTWufEEBWHDVQnS4SJWj1uue53GObydIUr2hXJsTmVmaxNa6TD+vZMyCvCPz2+zyzk5vDY3w=
X-Received: by 2002:a7b:c853:: with SMTP id c19mr753510wml.61.1544732585027; Thu, 13 Dec 2018 12:23:05 -0800 (PST)
MIME-Version: 1.0
References: <CAHw9_iK59mb2twkzkCd+at7=2=NfwvkPwuPCfT6kLx=WaBQ3zA@mail.gmail.com> <999BE505-0121-4298-BD02-D4B9EF436FC4@employees.org> <CAHw9_i+-H6v6Eq_EzVGmWhFtGXQgPgYE7HWEX9FGnLYw=ENWiA@mail.gmail.com>
In-Reply-To: <CAHw9_i+-H6v6Eq_EzVGmWhFtGXQgPgYE7HWEX9FGnLYw=ENWiA@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
Date: Thu, 13 Dec 2018 15:22:27 -0500
Message-ID: <CAHw9_i+09Vjz_TWWyYgkOhFj_quqKgO6mCSH8mmmGMyCXh+Bhg@mail.gmail.com>
To: Ole Troan <otroan@employees.org>
Cc: IETF Discuss <ietf@ietf.org>, opsec wg mailing list <opsec@ietf.org>, tsv-art@ietf.org, draft-ietf-opsec-ipv6-eh-filtering.all@ietf.org
Content-Type: multipart/alternative; boundary="00000000000000fd1b057ced150d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/biZMv3sUYknhSAXeRDldcRt0H7I>
Subject: Re: [OPSEC] Architectural implications of EH / filtering (was: draft-ietf-opsec-ipv6-eh-filtering)
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Dec 2018 20:23:12 -0000

[ Top-post, follow-up to my own mail]

I've had a chat with the rest of the IESG and I'm planning on going through
all of the (230+! ) emails again and classify them into:
A: related to the document itself
B: related to the larger "do intermediate routers have any role in
filtering" / "can devices actually do what it says on the tin" / related.
C:

I'd already done this, but only classified them in my head -- this will be
a large undertaking (and many emails fall into multiple categories) and
will take some time...

Also, a fair bit of the discussion felt like people talking past each other
- we will continue to investigate the information sharing / "recent changes
in protocol X" type sessions.
While looking into this I (re)discovered the "Technical Tutorials" (
https://www.ietf.org/about/participate/tutorials/technical/ ) page, but
what I hadn't known before was the
https://datatracker.ietf.org/group/edu/materials/ and
https://trac.ietf.org/trac/edu/wiki/Tutorial_by_IETF pages.
Many of these are a good way to get quick introduction to a new protocol /
sphere -- eg:
https://datatracker.ietf.org/meeting/101/materials/slides-101-edu-sesse-introduction-to-oauth-20-01.pdf

W


On Wed, Dec 12, 2018 at 4:54 PM Warren Kumari <warren@kumari.net> wrote:

>
>
> On Wed, Dec 12, 2018 at 3:32 AM Ole Troan <otroan@employees.org> wrote:
>
>> Warren,
>>
>> Thank you for your note.
>>
>> > On 12 Dec 2018, at 00:58, Warren Kumari <warren@kumari.net> 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...
>
> W
>
>
>> 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
> pants.
>    ---maf
>


-- 
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
pants.
   ---maf