Re: [secdir] Review of draft-ietf-ippm-ioam-data-11

[Shawn Emery <[e-mail]>]

Hi Frank,

Thanks for your response.  I've read
draft-brockners-opsawg-ioam-deployment-02 and still have concerns that
mitigating against eavesdropping, DoS/DDoS, and time synchronization
attacks, have not been sufficiently covered specifically regarding the data
tuple vector.

Regards,

Shawn.
--

On Thu, Dec 17, 2020 at 4:25 AM Frank Brockners (fbrockne) <
[e-mail]> wrote:

>
>
> *Hi Shawn,*
>
>
>
> *Thanks a lot for your review. Please see inline (..FB)*
>
>
>
> *From:* Shawn Emery <[e-mail]>
> *Sent:* Sonntag, 6. Dezember 2020 23:31
> *To:* secdir <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; Shawn
> Emery <[e-mail]>
> *Subject:* Review of draft-ietf-ippm-ioam-data-11
>
>
>
> Reviewer: Shawn M. Emery
> Review result: Ready with nits
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security
> area directors. Document editors and WG chairs should treat these
> comments just like any other last call comments.
>
> This standards track draft specifies data fields in the In-situ
> Operations, Administration,
>
> and Maintenance (IOAM) scheme.  The data fields contain operational and
> telemetry
>
> information in a network domain.  "In-situ" refers to the fact that the
> associated data is
>
> actually encapsulated in the data packet itself rather than through a
> separate OAM
>
> packet.
>
>
> The security considerations section does exist and describes multiple
> vulnerabilities
>
> to the IOAM.  Attackers can create both false-positives and
> false-negatives in regards
>
> to failures or the true state of the domain.  This can eventually lead to
> DoS attacks.
>
> Another form of DoS is by crafting an IOAM header to packets thereby
> increasing the
>
> resources required or exceeding the packet beyond the network's MTU size.
>
>
>
> Verifying the path of the data packets is deferred to
> draft-ietf-sfc-proof-of-transit's security
>
> consideration section which has good coverage and ways to mitigate the
> various attacks
>
> on the protocol.  Eavesdropping is also possible, which can reveal
> operational and telemetry
>
> data of the network domain.
>
>
>
> IOAM also utilizes timestamps, in which an attack on the time
> synchronization protocol can
>
> affect the timestamp fields in IOAM.  In addition the management
> functionality of IOAM could
>
> also be targeted, but suggests authentication and integrity checks to
> protect against said attacks.
>
>
>
> Various measures against these attacks are not prescribed based on the
> fact that this specification
>
> is about the data fields of IOAM.  However, I think it would be beneficial
> to provide some guidance
>
> (at least for future specifications) for each of these attacks
> that utilize these data fields else why
>
> articulate the security issues at all?
>
> *..FB: “…some guidance for each of the attacks…” very much hints at
> deployment considerations for IOAM. For that, we have an “IOAM Deployment”
> draft:
> https://tools.ietf.org/html/draft-brockners-opsawg-ioam-deployment-02
> <https://tools.ietf.org/html/draft-brockners-opsawg-ioam-deployment-02> in
> flight. The current thought model is cover all aspects of IOAM deployment,
> including guidance on mitigating security concerns, in this deployment
> draft. Would that be a workable approach for you?*
>
>
>
> *Thanks, Frank*
>
>
> General comments:
>
> None.
>
>
> Editorial comments:
>
>
>
> None.
>
>
>
> Shawn.
> --
>