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

[Tal Mizrahi <[e-mail]>]

P.S.
I believe Frank said he will request a slot in IETF 107 for the
working group drafts.
I will request a slot for the profile draft (which is not a working
group draft).
Any other IOAM-related slots?

Cheers,
Tal.

On Thu, Feb 20, 2020 at 2:43 PM Tal Mizrahi <[e-mail]> wrote:
>
> 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.