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

[Greg Mirsky <[e-mail]>]

Hi Tal,
thank you for the clarifying details. I believe it is highly risky to leave
outside the document the discussion of what security mechanisms, measures
are required from an iOAM domain to be considered as a "confined
administrative domain". I strongly encourage adding it to the document as
one of the sections. Then, these listed mechanisms and principles can be
referenced from the Security Considerations section to explain why iOAM
itself does not require the additional measures to protect data integrity
and/or confidentiality.

Regards,
Greg

On Mon, Jan 27, 2020 at 12:52 AM Tal Mizrahi <[e-mail]>
wrote:

> Hi Greg,
>
> Many thanks for the comments.
> Your point is well taken regarding the term "immediate export", and
> regarding clarifying the connection to integrity and confidentiality.
> There is a fundamental assumption in this draft that since IOAM is
> deployed in confined administrative domains, it significantly limits the
> scope of all the threats that are described in this section. Therefore this
> draft does not define any specific security mechanisms. This was a basic
> assumption throughout the process, and therefore the security
> considerations does not define any security mechanisms. However, I added
> some text that further clarifies this point.
>
> The following pull request includes my suggested changes to the Security
> Considerations following your comments:
> https://github.com/inband-oam/ietf/pull/146
>
> Cheers,
> Tal.
>
>
>
>
> On Sun, Jan 26, 2020 at 2:30 AM Greg Mirsky <[e-mail]> wrote:
>
>> Hi Tal,
>> thank you for your quick response to my comments. Please find my
>> follow-up notes in-line tagged GIM>>.
>>
>> Best regards,
>> Greg
>>
>> On Wed, Jan 22, 2020 at 12:33 AM Tal Mizrahi <[e-mail]>
>> wrote:
>>
>>> Hi Greg,
>>>
>>> Thanks for this comment.
>>>
>>> In the context of "confidentiality", since we are talking about OAM
>>> information, the correct context here is reconnaissance. Recon and its
>>> implications are indeed discussed in the Security Considerations section on
>>> the third paragraph.
>>>
>> GIM>> I find the text that you've referring too terse:
>>    The data elements of IOAM can be used for network reconnaissance,
>>    allowing attackers to collect information about network paths,
>>    performance, queue states, buffer occupancy and other information.
>> True, you name the problem but I don't see any discussion of how to
>> mitigate the risk of an intruder obtaining very sensitive information. What
>> mechanisms can be used to protect the confidentiality of data?
>>
>> Also, I've noticed the text that, I think, should not be in the document
>> in WG Last Call phase:
>>    Note that in case IOAM is used in "immediate export" mode (reference
>>    to be added in a future revision) ...
>> This is a simple editorial change but I'd appreciate it being done.
>>
>> And as we discuss confidentiality, I believe that
>> I-D.ietf-sfc-proof-of-transit must be in the normative list since the
>> security measures and mechanisms discussed in that draft are applicable to
>> this specification as well.
>>
>>>
>>> Regarding integrity protection, the first paragraph of the Security
>>> Considerations section discusses the consequences of compromising the
>>> integrity of IOAM.
>>>
>> GIM>> I am not sure that I can interpret the first paragraph in the same
>> manner as you. (As a side note, since RFC 7276 is used as the source of
>> information, I think it should be in the normative list of references). My
>> understanding of the first paragraph is that it explains that iOAM may be
>> used to produce a false-negative and/or false-positive view of the network
>> state. But I don't find any discussion on how to protect, how to make it
>> more difficult for an attacker to manipulate with or alter iOAM data.
>>
>>>
>>> In my opinion the current Security Considerations section covers the
>>> main threats related to IOAM, and also explains the rationale of not
>>> including explicit security mechanisms (the last paragraph of the section).
>>>
>> GIM>> On this I do agree. Security Considerations section names threats.
>> But I believe that it as well should include recommendations, options of
>> mitigating these risks, risk introduced specifically by iOAM transporting
>> information in data packets.
>>
>>>
>>> You make a good point that we did not explicitly use the terms
>>> "confidentiality" and "integrity", and I will suggest new text that
>>> explicitly refers to these terms in the relevant context of the section.
>>>
>>> Cheers,
>>> Tal.
>>>
>>>
>>>
>>>
>>> On Wed, Jan 22, 2020 at 8:52 AM Greg Mirsky <[e-mail]>
>>> wrote:
>>>
>>>> Dear All,
>>>> I'd like to add a note on the scope of the Security Considerations
>>>> section. While it discusses the potential use of iOAM as the new DDOS
>>>> attack vector, I didn't find a discussion of the protection of integrity
>>>> and confidentiality of collected data. As I understand, please correct me
>>>> if I've missed that in other sections of the document, all data is
>>>> collected and transported in the clear text, no provisions for
>>>> authentication or encryption except for Proof-of-Transit. I think that in
>>>> addition to stressing the importance of protecting the integrity of clock
>>>> synchronization and of the management plane, possible ways of protecting
>>>> integrity and, possibly, the confidentiality of collected data must be
>>>> discussed in the document.
>>>>
>>>> Regards,
>>>> Greg
>>>>
>>>> On Tue, Jan 21, 2020 at 3:56 PM Greg Mirsky <[e-mail]>
>>>> 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=
>>>>> [e-mail] <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
>>>>>> [e-mail] with your reviews and comments. Please indicate
>>>>>> whether you think this document is ready for publication.
>>>>>>
>>>>>> Best,
>>>>>> Tommy (as co-chair)
>>>>>> _______________________________________________
>>>>>> ippm mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/ippm
>>>>>>
>>>>> _______________________________________________
>>>> ippm mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ippm
>>>>
>>>