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 On Behalf Of Eric Vyncke (evyncke)
Sent: mercredi 10 août 2022 17:52
To: Internet Area ; int-...@ietf.org
Cc: ipsec@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
___
IPsec mailing list
IPsec@ietf.org
