By a 'colluding peer', I meant that both sides need to negotiate the same policy (e.g. this is sensitive data, so only allow encrypted traffic or vice versa). I think this boils down to how tight the admin policy is and also whether it is desirable to allow encrypted/clear policies for different services to the same server/cluster, which could result in the unintentionally attack I described below.
Thanks, - Ken ________________________________ From: Yaron Sheffer [mailto:yar...@checkpoint.com] Sent: Thursday, February 05, 2009 12:45 AM To: Grewal, Ken; Yoav Nir; Dragan Grebovich; ipsec@ietf.org Subject: RE: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Hi Ken, Yoav, I agree with Ken that the policy needs not be black and white, but for a different reason. Some people will treat deep packet inspection by middleboxes as an optional service: you want it for most traffic, but some traffic is too sensitive and you choose to prioritize confidentiality over malware protection. This model is definitely susceptible to attacks by infected endpoints that can control the IPsec stack, and e.g. attack a server using encrypted traffic. You don't really need a "colluding" peer - most peers will probably accept either an ESP-null or an ESP-encrypted proposal. But admins may be willing to take this risk. Thanks, Yaron ________________________________ From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Grewal, Ken Sent: Wednesday, February 04, 2009 20:25 To: Yoav Nir; Dragan Grebovich; ipsec@ietf.org Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Quote ... "Our use case is an edge device that inspects all traffic, and drops things it doesn't understand, such as non-NULL ESP and possibly SSL (they might make an exception for HTTPS, but do a MiTM attack against the SSL) " I do not think a typical policy will be black and white (allow ESP-NULL, drop ESP-encrypted), as traffic patterns will be mixed in reality (encrypted Vs. clear) and policy will dictate how a given traffic stream in inspected and if it is opaque then take the associated action (drop / bypass / apply QOS rules / send a different path in the network / etc...). e.g. There may be a secure channel to transfer highly sensitive data (e.g. payroll, company secrets, etc.) which should be encrypted and it may be undesirable to categorize this under a general rule - this is a simple extension of the firewall function. The 'bait and switch' attack where a connection uses ESP-NULL and then at a later stage uses ESP-Encrypted may also be possible unintentionally. E.g. Connection to a server (cluster / farm) to gain access to a 'normal' service uses ESP-NULL and then at a later stage, where the previous connection was torn down and a new one built, the connection is obtaining some sensitive data and is now using ESP-Encrypted. On the outside, the connection attributes look the same (same server IP, same client IP (but may be different client due to NAT), same SPI - SPIs can be reused for new connections to preserve fast lookups algorithms at recipients), but underneath the connection is to access a different resource (may be using a different port or service above the IP layer). If the intermediate device has a cached rule (based on the previous connection) indicating the traffic is clear, it will lead to falsely inferring the contents of the payload and undesirable results. This goes to my point on cache eviction policy for heuristics based intermediate devices, as highlighted in a separate thread. Reuse of the same 'tuple' with different traffic characteristics may be infrequent, but still plausible. I agree with Yoav that this attack may also be possible intentionally between two colluding parties, where the policy indicates all traffic is ESP-NULL. Thanks, - Ken ________________________________ From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav Nir Sent: Wednesday, February 04, 2009 12:04 AM To: Dragan Grebovich; ipsec@ietf.org Subject: Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments Dragan Grebovich wrote: Yoav I apologize for not being clearer earlier. I was not suggesting any new/different policy enforcement. I believe/agree that traffic visibility will matter only to a subset of traffic, but that is enforced at each appliance level, or on a more granular (per interface) level. Not all devices have to be capable of doing it, however if they are tasked to do it, they have to be able to scale and perform transparently and quickly. Therefore, if heuristics are turned on, all traffic will be subject to inspection (heuristic or deterministic), and then resource consumption matter. I definitely concur that not all ESP traffic will be NULL, but I believe your statement actually supports my point. When a packet hits a decision point, the following has to be determined asap: 1) Is the packet terminated here or am I to forward it? Until now, forwarded packets were always forwarded and no action was performed on the content. Now we may want to turn on a policy to inspect packet content which is not terminated here. 2) Can I do anything with it" (has it cleartext or IPSEC payload)? If cleartext - it is trivial ... 3) Is it AH or ESP? This is quick and trivial too ... 4) If it is ESP, is it ESP-NULL or full-ESP? If it is full-ESP, I can't do anything with it - pass (preferrably) or drop (if policy insists, but I doubt someone would prevent IPSEC, you never know). IMHO for each packet we have to perform the four steps. It is the implementation-specific choice whether it is deterministic or heuristic inspection to make a call. I need to make a call if it would take a few instructions or a chunk of code, potentially with some % of false-positives or false negatives. Again, I agree with you it may be "tweaked" to be close to 0%, however each additional discrimination requires more code, more cpu and more time to execute (latency). I am concerned that on large (high-end) devices this may take an unacceptably large toll. Dragan I don't think the use case is to inspect every packet like that. I also don't agree with what you wrote in #4. If the appliance is willing to pass ESP-non-NULL, then it doesn't really care about content inspection. That is fine, and probably the more common case, but in that case it shouldn't care whether a packet is or is not encrypted. Our use case is an edge device that inspects all traffic, and drops things it doesn't understand, such as non-NULL ESP and possibly SSL (they might make an exception for HTTPS, but do a MiTM attack against the SSL) So for each packet, the processing is something like this: 1. Is the protocol non-IPsec? if so, do the regular inspection 2. Is the protocol AH? if so, skip to the payload and do the regular inspection 3. Is the process ESP with an SPI and endpoints that have already determined to be NULL?: If so, skip to the payload and inspect. Note that this is a simple table lookup 4. Is this a new ESP SA? Do the heuristics, and then mark it in the table Of course it's possible for the endpoints to cheat, start of with ESP-NULL, and then after the heuristics marked it as OK, begin encryption. This "attack" will work if all your policy says is "ESP must be NULL". But that is not an interesting policy. Real policies will require deeper inspection of the internal flows, so the cost of the heuristics becomes negligible, as it only requires looking at the first few packets of each ESP SA. Email secured by Check Point Email secured by Check Point
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
