Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IPsec] draft-kivinen-ipsecme-esp-null-heuristics comments
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)
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).
--Paul Hoffman, Director
--VPN Consortium
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.