Subject: [ippm] On the integrity of IOAM data fields - new draft draft-brockners-ippm-ioam-data-integrity-00

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Mon, 25 Jan 2021 14:20:45 +0000

Dear IPPM WG,

During the IETF last call, there's been a discussion on how to ensure the integrity of IOAM data fields for those deployments that require it (see e.g. the thread below).

The IPPM chairs inspired an "integrity-00" draft to facility the discussion and evolve towards a solution. We've just published a first cut at discussing the different threads along with outlining different methods for addressing the integrity of IOAM data fields: https://tools.ietf.org/html/draft-brockners-ippm-ioam-data-integrity-00.

It would be great to get a view on which method you see as preferable and for what reasons, along with whether anyone has any additional methods/solution approaches in mind.

Thanks, 
Frank, Shwetha, Tal.

> -----Original Message-----
> From: Benjamin Kaduk <[email-masked]>
> Sent: Samstag, 28. November 2020 06:11
> To: Greg Mirsky <[email-masked]>
> Cc: Tal Mizrahi <[email-masked]>; [email-masked]; MORTON,
> ALFRED C (AL) <[email-masked]>; IPPM Chairs <[email-masked]>;
> [email-masked]; IETF IPPM WG <[email-masked]>
> Subject: Re: [Last-Call] [ippm] Last Call: <draft-ietf-ippm-ioam-data-11.txt>
> (Data Fields for In-situ OAM) to Proposed Standard
> 
> 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
> > <[email-masked]>
> > wrote:
> > >
> > > On Tue, Nov 24, 2020 at 11:30 PM Greg Mirsky <[email-masked]>
> > > 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
> > GIM>> 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