IETF Logo Mail Archive

Re: [Last-Call] [ippm] Last Call: <draft-ietf-ippm-ioam-data-11.txt> (Data Fields for In-situ OAM) to Proposed Standard

Benjamin Kaduk <kaduk@mit.edu> Sat, 28 November 2020 05:11 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5E53A0F35; Fri, 27 Nov 2020 21:11:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 3f01jZf3J14y; Fri, 27 Nov 2020 21:11:23 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 70FBD3A0EC2; Fri, 27 Nov 2020 21:11:22 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0AS5BE7j029698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 28 Nov 2020 00:11:19 -0500
Date: Fri, 27 Nov 2020 21:11:14 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: Tal Mizrahi <tal.mizrahi.phd@gmail.com>, last-call@ietf.org, "MORTON, ALFRED C (AL)" <acm@research.att.com>, IPPM Chairs <ippm-chairs@ietf.org>, draft-ietf-ippm-ioam-data@ietf.org, IETF IPPM WG <ippm@ietf.org>
Message-ID: <20201128051114.GO34187@kduck.mit.edu>
References: <160624221011.1004.4337499034959566457@ietfa.amsl.com> <CA+RyBmXp9dzH-G-d78Vho9obk5=xCz4xRxX55A5+OheC+nZyfw@mail.gmail.com> <CABUE3XnjamtznW6A99rojxpEutnzWvN92NNcvJg6PcitvQUDHg@mail.gmail.com> <CA+RyBmVvGvKysE+LrmQrCOi=QkjYzzh9nDPZ86Zphf+q8jj0YA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CA+RyBmVvGvKysE+LrmQrCOi=QkjYzzh9nDPZ86Zphf+q8jj0YA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/Ak2NAIKQ7p4Rij9jfv123xeTXQY>
Subject: Re: [Last-Call] [ippm] Last Call: <draft-ietf-ippm-ioam-data-11.txt> (Data Fields for In-situ OAM) to Proposed Standard
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Nov 2020 05:11:25 -0000

Hi Greg, Tal,

On Thu, Nov 26, 2020 at 12:14:42PM -0800, Greg Mirsky wrote:
> 
> On Wed, Nov 25, 2020 at 1:56 AM Tal Mizrahi <tal.mizrahi.phd@gmail.com>
> wrote:
> >
> > On Tue, Nov 24, 2020 at 11:30 PM Greg Mirsky <gregimirsky@gmail.com>
> > wrote:
> >
> > I would suggest to consider a new IOAM option that incorporates an
> > HMAC, which can be used alongside the conventional trace options. This
> > would allow an optional integrity protection capability for those
> > specific implementations that require it. This new option could be
> > defined in a new draft, allowing the data draft to proceed to
> > publication.
> >
> GIM>> I think that proceeding without addressing the essential security
> issue of the protocol might be premature and may produce implementations
> that are vulnerable to attacks.

Thanks for raising this topic.

Based on the discussion so far and skimming the first few sections of the
draft, I expect that I would put a discuss ballot in to ensure the
availability of a security mechanism such as this, which in effect would
negate the intent to "allow the data draft to proceed to publication".
That said, my stance could change as the thread continues or when I take a
closer look at the whole document, so it is okay (from my point of view) if
you (Tal) choose to wait and see if this does end up being a discuss point.
That said, I'd of course prefer if you and Greg can find a solution and get
it into place now :)

Thanks,

Ben

v2.23.0 | Report a Bug | By Email