Grewal, Ken writes: > Some people have jumped to conclusions that because we want to > differentiate between encrypted and non-encrypted traffic by > explicitly signaling in the packet, that WESP is now a replacement > for ESP. > > THIS IS NOT THE CASE AND IT WAS NEVER THE INTENT!
That is true, it was never intented for that, but some of the comments in the list (and in the last IETF meeting) started discussions which started to lead that way. This includes most of the WESP extension discussion. That discussion was the thing that woke me up, and then I started to notice that the WESP is very far from where it started. Even when most of the intermediate steps were justifiable, that does not mean the end result will be ok. > One item that may have led to this conclusion was the expanded ICV > over WESP, but this was introduced as a mitigation for certain > threats highlighted in the WG. Subsequent discussions have > determined that it would be better to mitigate these treats in an > alternative manner, so we can fall back to WESP being a wrapper for > ESP, without the expanded ICV. Wrapped ESP provides a wrapper for > ESP! The current draft still requires both checks, i.e. both ICV to cover the WESP header, AND checking all fields in the WESP header against other sources. I think the checking and ICV expansion happeneded about in the same time, and one of the reasons the checking of the fields is needed REGARDLESS whether ICV covers WESP header or not, is to protect against attacks where the end node puts wrong values to the WESP header to fool intermediate devices. ICV cannot protect against that. ICV will only protect against the attacks happening in transit, but checking all fields protects both for attacks happening in transit, and attacks done by the end node. > Some argue that we should use WESP for NULL traffic, mandating ESP > for encrypted traffic...AND ensure that ESP is NEVER used for NULL > encryption within a given domain / environment. How does an > intermediate device know that this policy is being enforced? It cannot, but on the other hand how can intermediate device know that the traffic which must be sent using ESP-NULL is not encrypted? Only way to do either of those, is to mandate them by policy, which do require co-operation from end point(s). > Having the encrypted flag within WESP allows clear and explicit > distinction that certain traffic is encrypted whereas other traffic > is not. This preserves the network based services we rely on and > also allows other access control policies to be enforced. E.g. I > want to ensure that my finance data flowing in the network is > encrypted and NOT using ESP-NULL. If I rely on ESP for encrypted > data and it can still use NULL encryption, I cannot enforce such a > policy from an access control tool. If you mandate that ESP is only for encrypted data, then you make policy which says that ESP is only for encrypted data, and thats it. If you cannot rely your end nodes to select correct policy between WESP-NULL and encrypted ESP, how can you rely them selecting correct policy for WESP-NULL vs encrypted-WESP traffic? I.e. your node can still use WESP-NULL for financial data or it can use encrypted WESP for traffic which should have been been using NULL cipher. > "A standards-track mechanism that allows an intermediary device, such > as a firewall or intrusion detection system, to easily and reliably > determine whether an ESP packet is encrypted with the NULL cipher; and > if it is, determine the location of the actual payload data inside the > packet." > > If we say that WESP is ONLY used to carry ESP-NULL (and ESP is used > to carry encrypted traffic, but based on the ESP spec and legacy, it > may also carry ESP-NULL), then we have not completed what we set out > to do, as we have failed to *reliably* determine if the ESP traffic > is encrypted or not! You can still use heuristics in that case, if you cannot update all your hosts which use NULL cipher to use WESP. Heuristics can also provide *reliable* way to determine whether traffic is encrypted ESP or not. That is why we have both heuristics and WESP. Heuristics are meant to be used in the mean time when not all traffic cannot be made to use WESP-NULL. After the whole network supports WESP-NULL you can forbid ESP-NULL by policy and drop heuristics. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
