Yaron Sheffer writes: > - Sec. 5. In the definition of IPsec flows, how is this done for (typically > tunnel mode) UDP-encapsulated ESP? Are port numbers part of the flow > definition? This text belongs either here or in Sec. 8.
Adding port numbers as part of the flow table might make some extra flows in case the NAT box is rebooted and port numbers change, but it is also safer assumption to do, as in case there is multiple clients behind the same NAT box talking to the same SGW, the port numbers is the only thing that differentiates those clients from each other. I added text to section 8 saying "Each unique port pair makes separate IPsec flow, i.e. UDP encapsulated IPsec flows are identified by the source and destination IP, source and destination port number and SPI number". > - 5. "Unsure" - if we choose the option of dropping such packets, are there > cases when retransmitted packets do not add any information and we will > remain forever "unsure"? It depends. If the packet is really encrypted ESP, then no, as each retransmission will have different IV, which means every packet will completely different, and that will make the heuristics to find out that flow is not ESP-NULL (i.e. Self describing padding checks will fail). If packet is ESP-NULL packet and is about known protocol (TCP/UDP) then simple checks given in the pseudocode work, i.e. we check that the source and destination port numbers are same for the retransmitted packet, and each of those will add some bits to the "Check_Bits" value, and when it reaches the threshold set in the policy the flow is recognized as ESP-NULL with given parameters. The problem case is that if only packets sent by the flow are of some unknown protocol, then heuristics cannot determine whether any of the fields in the protocol data are correct, thus it cannot determine the IV length. Even in this case the flow can be recognized as ESP-NULL packet with known ICV length, but unknow IV length if we get consistent next header fields in retrasmitted packets (as described at the end of section 9.2). > - 6, first paragraph. in to -> into Fixed. > - 6. This section seems to discuss the construction of an ESP-null detection > engine out of an off-the-shelf DPI engine. If this is the case, please say > so. The section describes relationship between the deep inspection engine and the heuristics, it is not necessarely related to the existing or off-the-shelf DPI engines. > - 9.1. 160, 192, and 256 bit algorithms are used -> 160, 192, and 256 field > lengths are used Fixed. > - 9.1. "Payload Data" is starred for some reason, probably cut-and-paste. Fixed. > - 10. The Security Considerations needs to have an explanation of what this > is good for, i.e. what security policy is enforced, what kind of DPI is > done. Also, (malicious) traffic can be encrypted in multiple ways, e.g. > simply by using TLS on top of TCP. One of the problems with using ESP-NULL is that I myself do not think there is really any good uses for it. The attackers can bypass it so easily by using encryption that I do not really know what kind of security policies can be enforced with it (unless you use disallow encrypted ESP compeltely, in which case heuristics come trivial). This is the main reason I do not see that WESP or heuristics will ever really get widely used anywhere. My reason for heuristics is that for those who want this kind of thing and who can explain themselves why they want it can implement them without messing up the IPsec implementations :-) The security considerations section already says that "The whole deep inspection for ESP-NULL flows only has the problem that attacker can always bypass it by using encrypted ESP instead of ESP-NULL unless that is not forbidden by policy." Changed that now to be: "The whole deep inspection for ESP-NULL flows only has the problem that attacker can always bypass it by using encrypted ESP (or some other encryption or tunneling method) instead of ESP-NULL unless that is not forbidden by policy." so that should cover TLS over TCP, or IP over DNS etc style bypassing methods... > In addition, we need to note the DOS potential of the ESP-null > detection process. Do we really? I think it is clear that any protocol can have bugs and implementation issues, but we do not list that in every single security considerations section (i.e. IKEv2 or AH or ESP). The DoS potential of the ESP-null detection is not any different than DoS potential of the IKEv2 implementation or ESP itself. > - Pseudocode: are we assuming one protocol per SPI? No. There can be multiple protocols going through the same SA. In some cases it is more efficient if multiple TCP packets are sent during detection process, but it works even if they come mixed in any way (i.e. when it checks if the last packet received had same TCP/UDP source/destination ports etc that is more efficient if the last packet really was part of same TCP/UDP flow than this current packet, but that is not required for correct operation). > At a higher level, shouldn't we have processing for tunnel mode ESP > as well? Yes, but to make pseudocode bit shorter, I left those out. As the description of "Example Pseudocode" says "It does not include all the required checks, and this is just example pseudocode". Section 9.3.5. describe what kind of checks can/should be done for the IPv4/IPv6 tunnel mode. As the introduction section says that "Because the traffic inspected is usually host to host traffic inside one organization, that usually means transport mode IPsec is used." and because of this I left those tunnel mode checks out from the pseudocode. Also firewall / deep inspection engine implementors usually have very good set of IPv4 and IPv6 header checks already in their products, so they can reuse those. Added comment about that to the pseudocode. > - Pseudocode: retreaved -> retrieved Fixed. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
