[Ippm-ioam-ix-dt] IPPM IOAM Meeting Minutes, November 25th, 2020

Tal Mizrahi <tal.mizrahi.phd@gmail.com> Wed, 25 November 2020 08:11 UTC

MIME-Version: 1.0
From: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Date: Wed, 25 Nov 2020 10:10:55 +0200
Message-ID: <CABUE3XkCszuCWvKtNdh3TN5zb9dHWppe=+LoagEUDmSc8WR47A@mail.gmail.com>
To: ippm-ioam-ix-dt@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm-ioam-ix-dt/uO4m5qqM7aySKNCBDoRw9enwLRs>
Subject: [Ippm-ioam-ix-dt] IPPM IOAM Meeting Minutes, November 25th, 2020
Precedence: list

IPPM IOAM Design Team
Virtual meeting
November 25th, 2020, 07:00 UTC
Webex meeting


Attendees:
Frank Brockners, Barak Gafni, Greg Mirsky, Justin Iurman, Tal Mizrahi.

Minutes by Tal Mizrahi.


Summary
=======
- Frank will update the IPv6 draft to address an issue regarding the
IPv6 tunnel destination address.
- Tal will propose some text to address some amplification scenarios
that were raised by Martin Duke.
- Some more discussion will continue on the mailing list regarding two
security issues in the data draft that were raised by Greg.
- The next meeting will be two weeks from now, December 9th at 07:00 UTC.


IPv6 Draft
==========
Frank: Justin is working on the IOAM implementation for the Linux
kernel. A few problems in the IPv6 draft came up as a result of this
implementation. Let's talk about that.
Github issue: https://github.com/inband-oam/ietf/issues/196
Justin: There is an issue about decapsulation. The IPv6 draft says
that the tunnel destination address should be the same as the inner
destination address. This is a problem. You have to make sure that you
are decapsulating the right packets. This is a security concern. This
is further discussed in the Github issue. Of course this creates an
issue regarding the destination address when you push the IP tunnel at
the IOAM encapsulating node; if you do not use the inner destination
address, there is a question how you know the tunnel destination
address.
Barak: Why do you need a tunnel?
Justin: A tunnel is required in order to comply to RFC 8200.
Barak: If you use the pre-allocated trace option then transit IOAM
nodes do not need to extend the IPv6 extended header.
Justin: That is right if the encapsulating node is the source host.
Barak: Right. If you use tunnels then you need to manage a lot of IP
tunnels. It sounds like a theoretical solution, not a practical one.
Frank: It is up to us to make sure that what we define in the draft
complies to the standard. 6man folks are concerned that if this is
deployed on the Internet then it needs to comply to the standard. Not
sure we can define how to determine the destination address. The
suggestion from Justin is to remove the requirement that the
destination of the outer tunnel is the same as the destination of the
endpoint, as this is a problem on the tunnel termination point.
Barak: Right, it is a problem to terminate a tunnel if you are not the
destination address. What is the suggestion?
Frank: Just drop this requirement. It needs to be a proper tunnel,
where the destination is the decapsulating node. It has operational
implications, but it is the right way to do it.
Justin: I have proposed on the Github issue to remove the sentence in question.
Barak: So what are you implementing at this point?
Greg: We need to mandate something if we do not want to violate RFC 8200.
Justin: For the Linux kernel at this point I will push the variant in
which the encap/decap node is the endpoint (no need for tunnels). Will
work on the tunnel variant in the future - will try to find a solution
for this.


Flag draft / DEX draft amplification scenarios
==============================================
Tal: Martin Duke introduced a couple of amplification scenarios.
https://mailarchive.ietf.org/arch/msg/ippm/PyfokOEsBBCTtRdNYG-Vr-674Nw/
Barak: Are these real scenarios?
Tal: They may occur in some cases. When we have more than one operator
(Namespace).
Frank: We may want to suggest some text that mentions these cases.
Tal: I will send some proposed text to the mailing list.


Data draft security comments
============================
Greg has sent security-related comments:
https://mailarchive.ietf.org/arch/msg/ippm/hzQMZ9n0GaRDreSa_PpizNodRiU/
Greg: Integrity protection can be provided by using HMAC, and tying it
with some information in the packet itself. It must be provided as an
option.
Frank: Do you really want another data field for that?
Greg: Yes.
Frank: The reason it is not there now is hardware implications.
Greg: The option should be there. Each node should have the ability to
protect its data.
Frank: We may need to address this issue in the draft.
Greg: Regarding Checksum Complement, it may be a concern. It is
similar to a zero checksum.
Tal: A Checksum Complement is different than a zero checksum. When a
Checksum Complement is used the destination still verifies the
checksum. The Checksum Complement is mathematically equivalent to a
conventional checksum, so this is not a security threat.
Greg: In my opinion there is a security issue that will need to be discussed.

[Ippm-ioam-ix-dt] IPPM IOAM Meeting Minutes, Nove… Tal Mizrahi