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 protected]> > wrote: > > É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 We incorporated the sentence that Magnus suggested. Thanks for agreeing to this! > > 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 We’ve responded individually to these reviews now. > > 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. Added: "This document only surveys point-to-point protocols; multicast protocols are out of scope." > > -- 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. Added a note that AH provides integrity. > > -- 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" ? I believe the use of “record protocol” here is correct, as the delineated data transport indeed is what we are referring to. > > 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). 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
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
