[Ippm-ioam-ix-dt] IPPM IOAM Meeting, December 9th, 2020

[Tal Mizrahi <[e-mail]>]

IPPM IOAM Design Team
Virtual meeting
December 9th, 2020, 07:00 UTC
Webex meeting


Attendees:
Frank Brockners, Greg Mirsky, Haoyu Song, Mickey Spiegel, Tal Mizrahi.

Minutes by Tal Mizrahi.


Summary
=======
- Tal will ping the AD and chairs regarding integrity protection of IOAM data.
- Frank will suggest text to address Shawn Emery.
- Haoyu presented a new draft about E2E RTT measurement.
- The next meeting will be on the 6th of January 2021, 07:00 UTC.


Data Draft
==========
Tal: some comments from Shawn Emery on the mailing list.
Frank: we have the deployment draft. There is some more detailed
security discussion there. I can add a note to the data draft
referring to this.
Tal: sounds good.
Frank: there was Greg's point regarding integrity protection. There is
probably going to be a new document about this.
Tal: so integrity protection solutions should be defined in a new document(s).
Frank: right, we may need a new document about this.
Greg: security considerations is a required component. Security of
IOAM is important. Draft that defines trace option format should have
an integrity protection solution.
Tal: as a reference, TWAMP authentication is pretty simple, since its
end-to-end. But, for example, NSH is much more complicated, because it
has intermediate points.
Greg: STAMP can be a reference.
Tal: integrity protection is complicated when you have both end-to-end
integrity and hop-by-hop integrity.
Greg: the hybrid two-step draft defines a mechanism that can be reused here.
Tal: each node would also need to verify the header in order to
mitigate modifications of the header.
Greg: not necessarily. From a protocol perspective, it can be solved.
Whether it is deployed or not is up to the operator. The hardware
constraints are important, but do not determine the protocol.
Mickey: that is not always true. In some cases implementations will
determine which protocols are deployed. Geneve is an example.
Greg: VMware have deployed Geneve.
Mickey: but that is not an example of a hardware implementation.
Greg: the IETF does not care about whether protocols can be
implemented in hardware or not.
Mickey: does the HMAC have constant length, or variable length?
Greg: we believe that 16 octets are enough.
Tal: it is certainly feasible to solve this problem, but a security
solution here is more complicated than previous protocols.
Greg: the security AD's feedback was that they will expect a security solution.
Tal: right, either way we will need our AD's support for this. As a
reference, NSH was published without security, and now the SFC WG is
working on a security document.
Greg: you will need to convince the security AD.
Frank: Tommy asked how complicated it would be to integrate some of it
into the data draft, and then cleanly create a security draft. We will
need to hear some more opinions.
Tal: we need some guidance from the AD and chairs, since the document
is in IETF last call.
Frank: right, we need some recommendation.
Tal: I am going to ping the AD and chairs about this issue, and try to
get some guidance.


Security of DEX and Flags Draft
===============================
Tal: Greg sent some comments to the mailing list about these two drafts.
Greg: I consider loopback as a special case of direct exporting, and I
believe that the active flag should not be there.
Tal: are you suggesting to drop the flag draft altogether?
Greg: Loopback: you can explain how DEX can be used for loopback.
Active: either has to be very restricted, or removed. Active OAM
protocols can be pretty easily filtered in existing protocols. That is
not the case with the IOAM 'active' flag.
Mickey: the flag distinguishes active OAM from conventional data.
Greg: but the flag is much 'deeper'. You need a lot of processing
before you get to the flag.
Mickey: not sure I understand the distinction.
Greg: it is a tool that can be used for attacking.
Mickey: you do not need the active flag to inject such an attack.
Greg: the active flag is an attack tool.
Mickey: the only thing you are doing differently is dropping the
active packets at the decap node. Other nodes don't care about this
flag.
Greg: imagine the active flag in NSH or segment routing.
Mickey: those are just domain endpoints.


New draft about IOAM RTT Measurement
====================================
draft-song-ippm-inband-e2e-rtt-measurement
Haoyu: this is intended for 5G use cases. We need a flag to tell the
other end to send back a packet. Suggest to add flags to the E2E
format.
Greg: have you looked at BFD echo?
Haoyu: no. We would be happy for feedback or related work.
Greg: the system controls the profile of the traffic. The RTT does not
necessarily reflect what you want to measure.
Haoyu: we are looking for inband measurement.
Greg: active OAM needs to be inband anyway.
Mickey: there is a large class of information that can be useful if
you send it back to the source. I would be interested if this could be
generalized.
Greg: you can use DEX and send the exported packet back to the source.
Mickey: then you are coupling the export format with the data format.
Greg: if you define the export format carefully, will it do the job?
Mickey: the exported format may be forwarded differently then the data format.
Greg: with careful configuration of the management plane this can be achieved.
Haoyu: we do not necessarily know when the feedback packet will be
sent if done in the management plane.
Greg: with segment routing you can program your segments in a way that
the packet loops back to you. Another thing to consider is to use BFD.