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

Hi Frank and Authors,
thank you for preparing this well-written and really mature document. I
fully agree with your opinion that IOAM security is not limited to
identifying potential attack vectors and mitigating threats. This document
provides implementors with a comprehensive set of mechanisms to protect the
integrity of IOAM data fields.
While the draft gives us a detailed analysis of the potential threats and
protection solutions for IOAM Trace Options, it could be helpful to expand
the scope of the analysis by adding the Direct Export mode of IOAM. I think
that for the Direct Export the native security mechanisms of IPv6, i.e.,
Authentication and Encapsulating Security Payload Headers (RFCs 4302 and
4303 respectively) can be used.

Regards,
Greg

On Mon, Jan 25, 2021 at 6:20 AM Frank Brockners (fbrockne) <fbrockne=
40cisco.com@dmarc.ietf.org> wrote:

> 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 <kaduk@mit.edu>
> > Sent: Samstag, 28. November 2020 06:11
> > 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>
> > 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
> > > <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
> > > 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
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>