Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data

Tal Mizrahi <tal.mizrahi.phd@gmail.com> Wed, 22 January 2020 08:40 UTC

Return-Path: <tal.mizrahi.phd@gmail.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1174120013 for <ippm@ietfa.amsl.com>; Wed, 22 Jan 2020 00:40:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 nT6XdR4IHQ6W for <ippm@ietfa.amsl.com>; Wed, 22 Jan 2020 00:40:08 -0800 (PST)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 79CD812008B for <ippm@ietf.org>; Wed, 22 Jan 2020 00:40:08 -0800 (PST)
Received: by mail-wm1-x329.google.com with SMTP id a5so5896841wmb.0 for <ippm@ietf.org>; Wed, 22 Jan 2020 00:40:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q+zB+IDTJ7priQkG5sasyIB7LGY0Hvlvfl7W0Cg1ptY=; b=o+poojOazcfO62cWeh3WA3n+9dUb16y5mFiQ+hYmz+bhM6d/Dl6sdnMEgC3ybfYWtX 63s1i9jEUi/hxbG8enm5O2+JFHQSzYoxeVirGEA6WrGgbrvgCYalwa8VZY4FPbQcMyHu Lkmz63IUQ7OLfm94dy654BP0d840VBCZgZaTcGmbdLX89KqV3MUOqnxL5dV6fUuuN8FA aKxMvELLimNlsNtQXkz12CSem/ptNJ8/2b2knhmX4eya5R2epmSv2eg9ZMZZniH9Iqhq LlIaX6ceSg63nEZX4yocIkUrckeHOFQGV5r/cjLrlQN4fG4yJl+dBfiU0dGahfRcAfR/ D0og==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q+zB+IDTJ7priQkG5sasyIB7LGY0Hvlvfl7W0Cg1ptY=; b=Vjek7Jq++EFQYUbQTo2ZhUCENFQXy/IO1L+ugf2hKifwaHwvse6jm5yO4gFIK2V6NI vy+zFv6uRED38spYioduBf8iKdM9/DLrBBTQG8NnSy5MlOYsa3Kvruz8neaNzfs+j+oG LwhwptesJE1cBDW1UWDNjzHuU/SKFkWmUrRcDZDmux/tO0D7EBfvZjFyEixQ6e7XWQ/D kud/TtQS3fJLHn4qU6m/UfC7y1iKFMkeXfw3hnELsOdGkpCpSTC5P7yel4AfC6WEMuH1 cTwZIRXGVBCR6KxW9fCMfNS9WHVCrjTf14qrkan4/nCiTrGw4E5A8+Oy1pIOfNkFdD1O 275g==
X-Gm-Message-State: APjAAAUG5TLnT7GGCvXc7s3hm41ZUr2vuYf3Jl3Url8Lkr//dvwcqTBS mH7AZn2RMp+KYWz/2dJofsb1KGidaW7j2RMudyo=
X-Google-Smtp-Source: APXvYqwn1b4Svg+liS/azZLUNYJ3ADPcj8esgBg2ek4MtXqmIrBiIRfnF29LBgU73xf7A3RkwAuzEjUZcJFMCMj+ov0=
X-Received: by 2002:a1c:7901:: with SMTP id l1mr1671708wme.67.1579682407025; Wed, 22 Jan 2020 00:40:07 -0800 (PST)
MIME-Version: 1.0
References: <E5725DE6-0637-4D52-BD61-2437D29D3C3B@apple.com> <CA+RyBmU8zgJzqA6USXY5jyQeGpV+6JZUntX5e0hkcjNEnvg3qA@mail.gmail.com>
In-Reply-To: <CA+RyBmU8zgJzqA6USXY5jyQeGpV+6JZUntX5e0hkcjNEnvg3qA@mail.gmail.com>
From: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Date: Wed, 22 Jan 2020 10:39:56 +0200
Message-ID: <CABUE3X=Wkdr8iYp5OPzv78qWkzHrc45M2An8o61cGNifbwkedw@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ba9055059cb67833"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/OEEPcOi1S0dPyocoO92vZ9weN44>
Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-ioam-data
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2020 08:40:11 -0000

Hi Greg,

Regarding your comment: "Checksum Complement may be practical but it raises
serious security issues. I couldn't find these being identified and
discussed in the document."

I am not sure I understand the serious security issues.
In my opinion the Checksum Complement does  not affect security in any way.
The following text regarding the Checksum Complement from RFC 7820
summarizes this point:

   It is important to emphasize that the scheme described in this
   document does not increase the protocol's vulnerability to MITM
   attacks; a MITM attacker who maliciously modifies a packet and its
   Checksum Complement is logically equivalent to a MITM attacker who
   modifies a packet and its UDP Checksum field.

Cheers,
Tal.


On Wed, Jan 22, 2020 at 1:57 AM Greg Mirsky <gregimirsky@gmail.com> wrote:

> Dear All,
> please consider my comments to draft-ietf-ippm-ioam-data as part of IPPM
> WG Last Call:
>
>    - In Abstract and Section 3, Segment Routing is characterized, among
>    other networking technologies, as a transport. RFC 8402 defines Segment
>    Routing as a method to leverage the source routing paradigm. Where else
>    could the Segment Routing be defined as transport?
>    - Also, "native IPv6" is mentioned in the Abstract as transport. Could
>    it be just a reference to IPv6? What is the significance of singling out
>    "native IPv6"?
>    - Introduction section explains the "in-situ" term as
>
>    The term "in-situ" refers to the fact that the OAM
>    data is added to the data packets rather than is being sent within
>    packets specifically dedicated to OAM.
>
> But with the introduction of Loopback and Direct Export as iOAM behaviors,
> iOAM data are not added to the data packet. And how these new iOAM
> functions affect the definition of IOAM control points in Section 3?
>
>
>    - I-D.lapukhov-dataplane-probe referenced as describing "recent active
>    probing mechanisms". That could have been the case in 2016 when the draft
>    was last time updated. But has expired and has not been discussed or worked
>    for 3.5 years.
>    - In regard to the control over iOAM, text in Section 3 states "It
>    SHOULD be possible to enable IOAM on a selected set of traffic ..." Does
>    that mean that not providing the selective enabling of iOAM is an
>    acceptable option?
>    - Further in Section 3, the requirement for encapsulation independence
>    is using SHOULD "Data formats for IOAM SHOULD be defined in a
>    transport-independent manner." What are the examples of exceptions?
>    - section 4.4 introduces the notion of an "iOAM capable node". Which
>    of iOAM objects are expected to be supported by the iOAM capable node? If a
>    node doesn't support a sub-set of iOAM data types, would it still be
>    considered as iOAM capable?
>    - Section 4.4.1 I'm having a hard time figuring how the presence
>    of Opaque State Snapshot space can be deduced. The explanation in NodeLen
>    is not clear to me.
>    - The definitions of Bit 0 and Bit 8 of IOAM-Trace-Type differ only in
>    part of the latter specifying that the format is wide. What is the length
>    on data identified by Bit 0?
>    - Hop_limit in Section 4.4.2 is defined as
>
>         This is copied from the lower
>          layer, e.g., TTL value in IPv4 header or hop limit field from
>          IPv6 header of the packet when the packet is ready for
>          transmission.
> What is the value of Hop_Limit field if the lower level does not include
> TTL/Hop Limit field?
>
>
>    - Four octets are allocated for timestamp subseconds in Section 4.4.2.
>    Both PTP and NTP have formats that can provide a higher resolution of a
>    timestamp. That likely to be useful where a higher resolution of time
>    measurement, e.g. delay variation is needed (for example, URLLC
>    applications of 5G, TSN or DetNet). Can iOAM data be extended in the future
>    to support a different length of the subsecond field?
>    - What was the rationale to choose nanoseconds as the unit for transit
>    delay?
>    - How future proof is allocating four octets to express the length of
>    an egress queue (queue depth)? What should be the value if an iOAM node
>    cannot write the local value in four octets?
>    - Similar to the questions above but in regard to the buffer occupancy
>    field.
>    - Checksum Complement may be practical but it raises serious security
>    issues. I couldn't find these being identified and discussed in the
>    document.
>    - Section 5 defers the specification of the particular timestamp
>    format used in the given iOAM Namespace to the management plane. Does that
>    mean that all nodes in the given iOAM Domain must support the same format?
>    In other words, timestamps collected in the domain required to be in the
>    homogeneous format - either all in NTP, all in PTP, or all in POSIX. That
>    looks like unnecessary complexity and limitation and may cause lower
>    accuracy of time measurement as an iOAM node may be required to transform
>    from its native time format into the format chosen by the management plane.
>
> Regards,
> Greg
>
> On Tue, Jan 7, 2020 at 8:47 AM Tommy Pauly <tpauly=
> 40apple.com@dmarc.ietf.org> wrote:
>
>> Hello IPPM,
>>
>> Happy New Year! This email starts a working group last call for "Data
>> Fields for In-situ OAM" (
>> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/).
>>
>> The last call will end on *Tuesday, January 21*. Please reply to
>> ippm@ietf.org with your reviews and comments. Please indicate whether
>> you think this document is ready for publication.
>>
>> Best,
>> Tommy (as co-chair)
>> _______________________________________________
>> ippm mailing list
>> ippm@ietf.org
>> https://www.ietf.org/mailman/listinfo/ippm
>>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>