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

"Frank Brockners \(fbrockne\)" <fbrockne=40cisco.com@xxxxxxxxxxxxxx> · Thu, 17 Dec 2020 11:25:04 +0000

Hi Shawn,

Thanks a lot for your review. Please see inline (..FB)

From: Shawn Emery <shawn.emery@xxxxxxxxx> 

Sent: Sonntag, 6. Dezember 2020 23:31

To: secdir <secdir@xxxxxxxx>

Cc: draft-ietf-ippm-ioam-data.all@xxxxxxxx; last-call@xxxxxxxx; Shawn Emery <semery@xxxxxxxx>

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

--

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call