Subject: [Taps] Éric Vyncke's No Objection on draft-ietf-taps-transport-security-11: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Thu, 09 Apr 2020 07:38:10 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-taps-transport-security-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. It is really easy to read.

After discussion with Magnus and Barry, I have cleared my DISCUSS but I still
hope for a fix to my previous DISCUSS

Please find below some non-blocking COMMENTs. An answer will still be
appreciated.

I hope that this helps to improve the document,

Regards,

-éric

== previous DISCUSS ==

I question the inclusion of CurveCP in the mix as per
https://curvecp.org/addressing.html it does not seem to support IPv6. At the
bare minimum, the I-D should mention this restriction in section 3 or rename
section 3 from "protocol descriptions" into something less exhaustive.

(and I hope to be corrected about CurveCP IPv6 support).

== COMMENT ==

Please respond to the IoT-directorate review by Mohit:
https://mailarchive.ietf.org/arch/msg/iot-directorate/xTVOvQ7kI78sDPZQuVsTvGB2x0s
Please respond to the INT-DIR review by Brian:
https://mailarchive.ietf.org/arch/msg/int-dir/2IHPgukaAAMvMjO7TXvo_ujcI_I +
Gorry Fairhurst's about GRE

Generic comment about the intended transport: all protocols analyzed in this
document are point to point (no multicast), this should probably be mentioned
in the introduction.

-- Section 1 --
Is there any reason why the integrity property of IPsec AH is not mentioned ?
Same also applies in section 2 when "security protocol" is defined.

-- Section 3 --
Use the wording of "record protocol" generically while the term "record
protocol" is defined in section 2 as a blocked data transport (like in TLS).
Suggest the use of "data transfer protocol" ?

An important property of such protocols is to be able to traverse a NAPT box
(that I hate)... I suggest to mention whether the analyzed protocols support
NAT-traversal in this description section or even in the analysis parts as
having a different view (application and network layers seeing possibly
different IP addresses so a potential impact on the API).

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 22 Apr 2020 10:28:18 -0700

Hi Eric,

Thanks for the review! You can find an updated version of the document here:

https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-ietf-taps-transport-security.html <https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-ietf-taps-transport-security.html>

Responses to your specific points inline.

> On Apr 9, 2020, at 7:38 AM, Éric Vyncke via Datatracker <[email-masked]> wrote:
> 

We incorporated the sentence that Magnus suggested. Thanks for agreeing to this!
> Gorry Fairhurst's about GRE

We’ve responded individually to these reviews now.
> document are point to point (no multicast), this should probably be mentioned

Added: "This document only surveys point-to-point protocols; multicast protocols are out of scope."
> Same also applies in section 2 when "security protocol" is defined.

Added a note that AH provides integrity.
> Suggest the use of "data transfer protocol" ?

I believe the use of “record protocol” here is correct, as the delineated data transport indeed is what we are referring to.

> different IP addresses so a potential impact on the API).

Thanks for bringing this up. We discussed as authors, and we don’t believe that interaction with NAT traversal is in scope for our analysis. There are, of course, transport protocols that handle this; and some security protocols (like IKEv2) have specific NAT-T extensions. However, this support does not modify or affect the contract between the security and transport protocols to my understanding.

Thanks,
Tommy

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 25 Apr 2020 14:26:36 -0700

> Added a note that AH provides integrity.

I note that per
https://mailarchive.ietf.org/arch/msg/ipsec/ykyUCKWzn9i0jBgHKhIVApJPLJk/ we
may not want to be adding new mention of AH.

-Ben

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 27 Apr 2020 06:55:34 +0000

Ben, thank you for the notice.

So, it seems that my suggestion was not up-to-date wrt IPsec and AH.

-éric

-----Original Message-----
From: Benjamin Kaduk <[email-masked]>
Date: Saturday, 25 April 2020 at 23:26
To: Tommy Pauly <tpauly=[email-masked]>
Cc: Eric Vyncke <[email-masked]>, Philipp Tiesel <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-taps-transport-security-11: (with COMMENT)

    I note that per

    -Ben