Hi ipsecme,
An open issue we have for IPTFS is the use of transport mode. During the last face-to-face IETF meeting transport mode was mentioned, and my response had been that transport mode was less secure than non-TFS tunnel mode as the IP header was leaking user information so it hadn't been a consideration for us; however, it was later pointed out (by Paul W. I believe), that transport mode is (unfortunately?) commonly used with GRE tunnels in lieu of IPsec tunnel mode so we probably still needed to handle this case. Key to TFS is sending data even when there is none from the user and also changing the rate at which we send the user data. This means that we need to be able to generate empty packets, and we need to be able to consolidate user data packets. This is the primary hurdle in handling transport mode, it means that we must cache information from the user connection in order to generate empty packets, and we must also be able to aggregate user data packet headers. For the common case of GRE/tunnel (which is the main justification for use of transport mode IMO), the GRE header information should be stable, and relatively easy to cache/consolidate for regeneration/aggregation. Handling only this case is relatively easy, We should be able to use the last received header information to generate new headers for empty packets, likewise aggregating headers should also work as each IP header should be the same. This simpler solution requires specification of what IP header fields are expected to be the same packet to packet. It means that certain things in the user IP header should not be present as well, like IP fragmentation/reassembly data, or per packet varying IP options/extension headers. IP fragmentation: - For the GRE/tunnel case we could mandate that the GRE tunnel packets need to arrive at IPsec un-fragmented. - For a more generic transport case IP fragmentation in the unencrypted header is a leak of user information so we would need to hide it (starts seeming like a tunnel again) IP options/IPv6 extension headers: - These would need to remain stable, or leaving them off or repeating them would need to be OK. - For the the GRE/tunnel case this hopefully would be straight-forward - Unsure on how to specify this for more generic case. We believe that there's enough complexity in the handling and specification of TFS for transport mode that we should address this mode in a separate draft. This will allow us to get the less complex TFS tunnel mode specified while we continue to work on the various aspects of how best to handle TFS transport mode. We would be happy to work with other interested folks to write this TFS transport mode draft. Thanks, Chris.
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
