Magnus A simple mention of the lack of IPv6 in section 3 of the description would be more than enough for me.
-éric -----Original Message----- From: iesg <[email protected]> on behalf of Magnus Westerlund <[email protected]> Date: Thursday, 9 April 2020 at 14:16 To: "[email protected]" <[email protected]>, Eric Vyncke <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, Mohit Sethi M <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: Éric Vyncke's Discuss on draft-ietf-taps-transport-security-11: (with DISCUSS and COMMENT) Hi Eric, Aren't you going a bit to far now with this discuss? Yes, IETF stream procotocols are expected to support IPv6. This is a non-IETF devleoped security protocol which is investigated from the perspective of its features to influence considerations of required API surface for security features. All discussed in relation to a set of aspects where the only one having to do with addressing is source-address valdiation and which CurveCP do not support as particular relevant. I don't see how it is going to affect or impact that future work in TAPS WG.. Why do you think an aspect of a protocol that isn't discussed being relevant to mention? If you have a good reason fine then a disclaimer could be added. But I don't see how it would not result in a unconnected comment on a specific protocol which has no connection to the purpose of the document. Cheers Magnus On Thu, 2020-04-09 at 03:01 -0700, Éric Vyncke via Datatracker wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-taps-transport-security-11: Discuss > > 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/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. It is really easy to read. > > Nevertheless, I am balloting a DISCUSS (see below), I sincerely hope that I am > wrongly asserting the lack of IPv6 support for CurveCP else the easy way to > clear my DISCUSS would be to mention this limitation in section 3 even if the > focus of this I-D is on the API. > > Please find below some non-blocking COMMENTs. An answer will be appreciated. > > I hope that this helps to improve the document, > > Regards, > > -éric > > == DISCUSS == > > I question the inclusion of CurveCP in the mix as per > https://protect2.fireeye.com/v1/url?k=c6d9b121-9a0dbd7f-c6d9f1ba-8691959ed9b7-6efcfea6e017deb9&q=1&e=d62bfe3e-4eac-4ef1-877e-ac1f40b4418d&u=https%3A%2F%2Fcurvecp.org%2Faddressing.html > it does not seem to support IPv6. At the > bare minimum, the I-D should mention this restriction in section 3. (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). > > > -- Cheers Magnus Westerlund ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: [email protected] ---------------------------------------------------------------------- _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
