[Ippm-ioam-ix-dt] IPPM IOAM Virtual Meeting, Feb 19, 2020

[Tal Mizrahi <[e-mail]>]

IPPM IOAM Design Team
Virtual meeting
February 19th, 2020, 07:00 UTC
Webex meeting


Attendees:
Frank Brockners, Barak Gafni, Greg Mirsky, Tal Mizrahi, Mickey Spiegel.

Minutes by Tal Mizrahi.


Summary:
========
- Tal has updated the pull request regarding the security
considerations of the data draft based on the discussion below:
https://github.com/inband-oam/ietf/pull/146
- Mickey will suggest a text udate to address the timestamp issue in
the data draft.
- Frank will work on updated text to address other open issues in the
data draft.
- The next virtual meeting will be on March 4th, 07:00 UTC.


Detailed discussion:
====================
- Tal: an updated version of the DEX draft was posted as a working
group document. The main open issue is related to the hop limit/hop
count, and was presented on the mailing list. No comments yet. Any
suggestions on how to proceed?
- Frank: we can continue with the email discussion.
- Tal: an updated version of the flag draft was posted with updates
based on comments and discussions in the design team. The loopback on
the reverse path is an open issue. No comments received yet. Another
open issue is security and amplification attacks. Some text was added
to this draft, but no feedback yet. Greg - any comments about
security?
- Greg: will look at the draft. Also the open issue of the loopback
reverse path needs more discussion. Maybe we should discuss the
security issues in the data draft first.
- Tal: moving on to the data draft - we have a pull request regarding
security that tries to capture our understanding of the security
considerations.
- Greg: if IOAM traverses inter-data-center links, how do you secure that?
- Tal: inter-data-center has to be secured anyway, regardless of IOAM.
- Greg: for example, Geneve has security mechanisms.
- Tal: what if we explained in the draft that some of the security
would have to be defined on a per encapsulation basis?
- Greg: some considerations in Geneve may affect IOAM.
- Tal: we need to explain that some security considerations will have
to be defined on a per encapsulation basis.
- Greg: that may help. Whether security mechanisms are used is not the
same question as whether security mechanisms are defined. This
document is the base for other encapsulations.
- Tal: we are looking to scope the security threats and requirements,
but this draft should not define security mechanisms.
- Greg: if we do not define security mechanisms then we are not
providing any solutions.
- Mickey: there may be various scenarios for IOAM. What is the scope
of your concern? Only inter-data-center?
- Greg: you may be exposed in inter-data-center similarly to exposure
on the Internet.
- Frank: is the concern that IOAM packets are changed by transit node,
or is it that there may be IOAM nodes that malfunction? The first
concern is not specific to IOAM.
- Greg: there is a specific discussion about IOAM - whether it is
fault management or performance management. In other protocols we have
integrity protection.
- Frank: right, but in that case we are also concerned about integrity
protection for data.
- Greg: Geneve has integrity protection. It would be a good step
forward that in specific encapsulations it would be useful to use
specific security mechanisms. If there is no security mechanism, it is
not available to encapsulations.
- Mickey: it depends on the deployment scenario.
- Greg: if there is no security mechanism, then you can't use IOAM in
a scenario that is subject to threats.
- Frank: security is a concern. You can either ignore it, or you can
address it in the draft. I would suggest to address it by adding a
paragraph that explains this.
- Tal: I agree. We should add a paragraph that explains that in some
scenarios and encaps we will need a security mechanism, but will not
be defined in this draft.
- Mickey: adding a security mechanism makes sense for DEX, but how
does it fit the data draft?
- Frank: for example, a Geneve tunnel between IOAM hops can be
secured. The links between IOAM hops can be secured in some cases.
- Mickey: in DEX you can secure the data.
- Frank: an attacker can still add a DEX option.
- Mickey: for inter-data-center is there a concern that the tunnel
extends across more than one administrative domain?
- Greg: it does not matter where the tunnel is terminated. If the
packet is not protected it can be modified. It would be a good idea to
have at least some text that mentions this may be necessary in other
drafts.
- Mickey: you may or may not require these mechanisms depending on the
deployment scenario.
- Tal: will update the pull request, and let's discuss the text.
- Frank: going over the issues, and will try to update the text in the
next few days.
- Tal: the next meeting is on the 4th of March. Will try to have text
suggestions before that.
- Mickey: most of the issues should be simple. Security may require
more iterations. I will try to find some text for timestamp
boundaries.
- Mickey: the raw export draft expired a month ago. I will refresh it.
- Tal: we need to request a slot for IETF 107, to discuss the working
group documents.