Hi Tero, Let me answer the very relevant question you have raised and got no reply for yet. Let me first give you a short background.
We had a similar discussion on ESP-NULL versus AH and merits of a heuristics approach in 2007 on the SAAG list. You can have a look at the discussion http://www.ietf.org/mail-archive/web/saag/current/msg01933.html and the related mails. Tero Kivinen's point at that time too was that we can do heuristics based approach. Also look at the archive http://www.ietf.org/mail-archive/web/ipsec/current/msg01902.html of the question I had raised. > Raises a question, why is this all needed? What is the use case? > Neither this, nor WESP draft can give a simple answer for the > question. If encrypted traffic is allowed to pass traffic > analyzer/intrusion detector/intrusion prevention/firewall/whatever, > the malicious end nodes will use encryption. If encrypted traffic > is dropped by intermediate, then there is an end node policy > issue. Detection whether an ESP packet payload is encrypted or > not should already be fast on deep inspection packet matching > hardware. Like mentioned in the mail assume an application that runs within an enterprise and uses ESP-NULL only service. We could filter out all packets for that application port at the firewall itself as we can look deeper into the packet if we had a mechanism to know if the packet is encrypted or not. So if an encrypted packet came for an SA which used ESP-NULL, it would not be processed properly and dropped like you mentioned by the application anyway. However by knowing ESP-NULL at the edge we could drop packets for applications from domains disallowed to send packet in (even though the packets are replayed packets and so will actually be treated as correct packets by the application). This is also one reason an application may use ESP-NULL, that way firewalls can do their work and the application is safe from being bombarded by packets from outside the domain. The use cases of doing the detection of ESP-NULL versus encrypted packets however are limited. Thanks, Vishwas _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
