From nobody Sun Dec 6 14:31:15 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19033A0CB7; Sun, 6 Dec 2020 14:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ki1oEtBgxNIk; Sun, 6 Dec 2020 14:31:06 -0800 (PST) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096673A0CB5; Sun, 6 Dec 2020 14:31:02 -0800 (PST) Received: by mail-ej1-x62d.google.com with SMTP id x16so16763592ejj.7; Sun, 06 Dec 2020 14:31:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=p7mQpihJG6IAAg02Y6uxQFmGAeaP4gsF5PalgRiNCuA=; b=i75QEZePWl+bJhxI7ojw+j+ldr3OZsrxqb6B7FDN/T2cAOIeOXULrHodklZwjtfhoQ nRT4aAmrVdOhmxoG/UcT9Kh/9ZXJEPdE/b6f+Q7OE7Z+RUxhfPMPdjjIuEUfuDLLp/NB haftGKf7WIAxwkHfnfv94brecaHAPYkMYoayMgKQWXyJs0NSY1gcUMCMevoW4+F4uJ7I Nabb9vq6k/zAtN1r22IYpQJIKbyHALqplwd+XiNHRIDQrOipPxqxTgrFp5mKI5zDtIrQ wEDwBqFJtjjVuVuLm5liD7rTbvc8mOx+7SMorfXv0XuZMP49l87WYpCrXM4KoU9SqpGJ biUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=p7mQpihJG6IAAg02Y6uxQFmGAeaP4gsF5PalgRiNCuA=; b=nAdFNYijk5TnCV8uj1MW7q913fgyAyzdJYqmzq69Fq78kjBkUfwJN+AYowWfF5HPgQ dgTNDs8NWr21Qtvi/T18eyRCp0sV46J9ea5aD/ZofZYV1qgPleTMacfO8nkbB2SU+JA/ NAIwWWMTk4aevUp2DbK50qe8gwdM0QCywavvWKW3MEX+68pWf3FVUCyvh1i9kJdnsi7U EEOAHjMlTsAvva50YHFoe3b6kyknSGfPwo/5gP/M8k99lhgZHlx+Cii0O3zsD76ufciB AyDGi6XrS6+ypEt9JScU0WgbjT6spsawUUu16MvbPV7r/d+viPuwrAGZ0filDE5qh6Yy S8/A== X-Gm-Message-State: AOAM530OKyVLrJfbrYp2PBEmSEwiMia5r1o3NN+7CiEvb81fBeCBEytG +i2tPGDor0xmQjM5IwOm1dVxXPl/kI+TTjZJF3gQj1wfKAiEww== X-Google-Smtp-Source: ABdhPJzWuHfOdeKYHLh/uvuxax4vYpCA+LeY06m/PYKx+SWJGdctE+BXleieclk/kh3y68aoK0RmRGlysJhMAqyk2kk= X-Received: by 2002:a17:906:c7d9:: with SMTP id dc25mr16838311ejb.138.1607293860884; Sun, 06 Dec 2020 14:31:00 -0800 (PST) MIME-Version: 1.0 From: Shawn Emery Date: Sun, 6 Dec 2020 15:30:44 -0700 Message-ID: To: secdir Cc: draft-ietf-ippm-ioam-data.all@ietf.org, last-call@ietf.org, Shawn Emery Content-Type: multipart/alternative; boundary="000000000000a0b53c05b5d3436d" Archived-At: Subject: [secdir] Review of draft-ietf-ippm-ioam-data-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2020 22:31:10 -0000 --000000000000a0b53c05b5d3436d Content-Type: text/plain; charset="UTF-8" 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? General comments: None. Editorial comments: None. Shawn. -- --000000000000a0b53c05b5d3436d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reviewer: Shawn M. Emery
Review result: Ready with nits=

I have reviewed this document as part of the security directorate&#= 39;s
ongoing effort to review all IETF documents being processed by the = IESG.
These comments were written primarily for the benefit of the secur= ity
area directors. Document editors and WG chairs should treat thesecomments just like any other last call comments.

This standards tra= ck draft specifies data fields in the In-situ Operations, Administration,and Maintenance (IOAM) scheme.=C2=A0 The data fields contain operational= and telemetry
information in a network domain.=C2=A0 "In-si= tu" refers=C2=A0to the fact that the associated data is
actu= ally encapsulated in the data packet itself rather than through a separate = OAM
packet.

The security considerations section doe= s exist and describes multiple vulnerabilities
to the IOAM.=C2=A0= Attackers can create both false-positives and false-negatives in regards
to failures or the true state of the domain.=C2=A0 This can eventu= ally lead to DoS attacks.
Another form of DoS is by crafting an I= OAM header to packets thereby increasing the
resources required o= r exceeding the packet beyond the network's MTU size.

Verifying the path of the data packets is deferred to draft-ietf-sf= c-proof-of-transit's security
consideration section which has= good coverage and ways to mitigate the various attacks
on the pr= otocol.=C2=A0 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 synchroniza= tion protocol can
affect the timestamp fields in IOAM.=C2=A0 In a= ddition the management functionality of IOAM could
also be target= ed, but suggests authentication and integrity checks to protect against sai= d attacks.
=C2=A0
Various measures against these attack= s are not prescribed based on the fact that this specification
is= about the data fields of IOAM.=C2=A0 However, I think it would be benefici= al to provide some guidance
(at least for future specifications) = for each of these attacks that=C2=A0utilize=C2=A0these data fields else=C2= =A0why
articulate the security issues at all?

General comments:

None.

Editorial comments:

None.

= Shawn.
--
--000000000000a0b53c05b5d3436d--