Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments

["Grewal, Ken" <ken.grewal at intel.com>]

>At 2:33 PM -0700 2/10/09, Grewal, Ken wrote:
>>Stateless firewalls are commonly employed for efficiency and as a crude
>method for cutting off access to certain services - these are useful for
>basic access control in cost effective, high bandwidth, network scenarios.
>E.g. Corporations may not want to allow various P2P protocols, discovery of
>resources, access to certain services (especially if using UDP as the
>underlying protocol), remote access/management to certain resources from
>outside well established network boundaries, etc., etc.. There are
>thousands of well defined ports providing different services from legacy,
>experimental, to the 'latest, greatest, service of the day' - and someone
>just found an exploit for and there is no fix available! How do you ensure
>that your network doesn't get inundated with unwanted traffic or exploited?
>Block that port!!
>>
>>Stateless firewalls can and do provide the fundamental building blocks for
>basic access control. In these scenarios, the need to differentiate between
>encrypted / NULL ESP traffic is required to enforce these policies, without
>the need or burden of keeping state on 'connections' or 'security
>sessions'.
>
>(Not wearing any hat)

[Ken] Wearing a basketball hat - 'go blazers!' :-)

>
>What level of assuredness do stateless firewalls need? That is, a stateless
>firewall can easily look inside what it is passing to get a simple guess
>about what is in the packet; this happens all the time on port 80. There
>are well known but imperfect heuristics for inspecting content on port 80;
>some of those could be used on ESP as well.
>
>People commenting on this thread should state what level of certainty they
>think the middleboxes need to have, in addition to saying what properties
>they think those middleboxes have (such as ability to retain state, how
>much state, how long, and so on).

[Ken] In some cases, the certainty must be 100%, otherwise there is no control. E.g. A new exploit has just been published for certain types of traffic - published vulnerability where a virus/worm can exploit a 'buffer overrun/stack overflow' condition for a given piece of software providing a given service, which subsequently allows a hijacker to take control of the machine/server. That service MUST be shut down to ensure that the vulnerability cannot be exploited and spread. This may or may not result in shut down of the server hosting the service, as you may want to allow remote patching, etc. Easiest way to do this is to block the port over which the vulnerability is being exploited. 

Just one example and I am sure there are numerous others...