Merci Antoine for your review. When I updated my ballot position [1] from DISCUSS to NO OBJECTION, I have also referred to your email and strongly asked the authors for a reply.
Regards -éric [1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ballot/ From: Antoine FRESSANCOURT <antoine.fressanco...@huawei.com> Date: Monday, 5 September 2022 at 15:12 To: Eric Vyncke <evyn...@cisco.com>, Internet Area <int-area@ietf.org>, "int-...@ietf.org" <int-...@ietf.org> Cc: "ip...@ietf.org" <ip...@ietf.org> Subject: RE: Can you review draft-ietf-ipsecme-iptfs as it is about tunnels Hello, Following the message from E. Vyncke on the Int-Area mailing list, I have made a review of draft-ietf-ipsecme-iptfs-19. As it is my first draft review, I hope it will bring value to the author. I am of course happy to discuss comments on list or off list. The draft draft-ietf-ipsecme-iptfs-19 proposes a mechanism to obfuscate and anonymize flows going through an IPSec tunnel. In the proposed mechanism, packets of fixed size are sent at a constant rate in the tunnel. Packets traversing the tunnel may be multiplexed or fragmented in the tunnel using an AGGFRAG payload conveyed in the ESP of an IP packet. One of the benefits of this mechanism compared to previously presented mechanism is to improve the bandwidth efficiency and improve the throughput for packets inside the tunnel. This work solves an important security / privacy attack, the traffic flow correlation attack, consisting in analyzing the pace and size of packets exchanged between hosts to determine which application is used. Recently, authors of the paper ditto: WAN Traffic Obfuscation at Line Rate [1] have presented a solution similar to the solution presented in this draft. Note that this work could appear in the implementation section 8 as the authors have published an open source implementation of their work (Or in the informative references). I have two major remarks about the document: 1/ In section 2.4.1, the author mentions that “Non-congestion-controlled mode is also appropriate if ESP over TCP is in use [RFC8229]. However, the use of TCP is considered a highly non-preferred, and a fall-back only solution for IPsec. This is also one of the reasons that TCP was not chosen as the encapsulation for IP-TFS instead of AGGFRAG.”. while no mention of QUIC is made. I understand that the draft has been in the work for a rather long period of time, and that some recent QUIC work have popped out while it was in the making, yet I think it would be interesting to position this draft with regards to RFC 9221 (An Unreliable Datagram Extension to QUIC) given that QUIC now provides some tools and mechanisms that are similar to the tools needed by the authors (alas at a different layer, which is a major difference between the mechanism proposed in the draft and QUIC) 2/ About the congestion mode, the draft is referring to RFCs 3168 and 6040, which discuss the potential problems associated with the use of ECN in an IP in IP tunneling mechanism. As ECN is not protected in IP Sec, the Security Considerations section explicitly discourages from using ECN by default. Yet, I think that some threats related to the use of the congestion mode in this draft should be explicitly stated in the document. For instance, adding congestion on links taken by the tunnel can force the receiver end of the tunnel to signal that congestion is experienced. An observer being able to look at the sender end’s inbound traffic could determine which flows / other tunnels are delayed in front of this congestion event, leading the attacker to gain information about the tunnel’s users. This attack requires a rather powerful attacker, yet is considered feasible in the literature about privacy-preserving communication. I would discuss this potential threat in the Security Considerations section as a complement to the paragraph about ECN. Overall, I think the draft is very interesting, that the technology it presents is useful and while I would appreciate some answers to remarks I have made, I think it is ready for the next stage. Best regards, Antoine Fressancourt [1] Meier, Roland, Vincent Lenders, and Laurent Vanbever. "ditto: WAN Traffic Obfuscation at Line Rate." NDSS Symposium 2022. 2022. From: Int-area <int-area-boun...@ietf.org> On Behalf Of Eric Vyncke (evyncke) Sent: mercredi 10 août 2022 17:52 To: Internet Area <int-area@ietf.org>; int-...@ietf.org Cc: ip...@ietf.org Subject: [Int-area] Can you review draft-ietf-ipsecme-iptfs as it is about tunnels Dear intarea/int-dir, I have a request for you about https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ While the draft name looks like it is about IPsec, it appears to me as an “aggregation and fragmentation” tunneling mechanism [1], i.e., it uses the ESP Next-header field (an IP protocol per section 2.6 of RFC 4303 == IPsec ESP) to indicate a next protocol. While the original intent is to prevent traffic analysis (based on packet size and rate of packets) by padding/aggregating/fragmenting packets, it is also a tunnel. This smart technique could be use above other protocols than ESP. I have just deferred the IESG evaluation of this document to allow the int-dir and intarea WG to review this document as it has most probably escaped your filter during the IETF Last Call. Thank you very much for your comments (please keep all lists in cc) Regards -éric [1] vaguely related to draft-templin-intarea-parcels
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
