[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-vandevelde-v6ops-nap-01.txt - "maybe add a bit more on proxy servers ..."
Hi John,
On Wed, 16 Mar 2005 19:21:38 -0800
"John Spence, CCSI, CCNA, CISSP" <jspence@native6.com> wrote:
>
> This draft does a great job of summarizing why engineered network security
> (NAP) is much better than side-effect security (NAT).
>
> There are probably a few places to expand upon the discussion of proxy
> servers within a NAP-based security program. NAT and proxies are not the
> just the same thing at different levels of the ISO stack. NAT does simple
> address translation, whereas proxy implementations - especially in larger
> enterprises - do much more, including caching, L4-L7 security functions, and
> policy enforcement. Proxies also do a great job of topology hiding.
> <snip>
Unfortunately, proxys break the end-to-end argument, as they maintain
state within the network. If the proxy breaks, devices would not be able
to access the resources they may still have an IP layer path to. Proxys
are worth avoiding for the same reason NAT is.
Geoff Huston wrote an execellent paper discribing the issues that
"middleware" (the generic name for things such as proxys) cause in
networks. You can download it at
http://www.potaroo.net/ispcol/2001-04/2001-04-midware.pdf
He has a number of other insightful papers on his "ISP Column" web page
at
http://www.potaroo.net/ispcol/index.html
All the policy mechanisms you mention really are best done on the end
host itself. There are two main reasons. Firstly, the application of
policy doesn't rely on a known topology of the network. Consider a
non-IT person bringing in a cheap wireless AP they bought on the week
end, and inserting it at their wired wall point. Upstream "policy
applying devices", such as firewalls, proxy servers etc, aren't
necessarily effective anymore, as they won't see the wireless traffic.
If the corporate policy was deployed to the node itself, it doesn't
matter what the network topology is anymore, nor whether it changes
surrepticiously or not. I first came across this idea in Steve
Bellovin's paper, "Distributed Firewalls",
http://www.cs.columbia.edu/~smb/papers/distfw.html
Secondly, deploying policy to the end hosts also provides the best user
granularity with the policy, as generally, it is one end-user to one
host. Identifying users at a per-host level tends to be easier than
network based identification mechanisms. They also tend to be more fault
tolerant, as a failed policy (e.g., deny all access) on a user's host
only effects the single user, rather than a significantly larger
user population.
I'm not necessarily saying all the mechanisms currently exist to a level
of maturaty to do what I'm suggesting. However, when we are considering
the future, such as IPv6, I think it is better to move on from less
useful mechanisms, such as NAT and proxys, sooner rather than later.
Specific topology hiding mechanisms such as NAT or Proxys aren't that
useful in IPv6, as, due to the size of the IPv6 address space, topology
discovery techniques such as "sweep pings" become impractical. Tony Hain
pointed this out a while back on the IPv6 mailing list. For example,
(and I've explored this a bit more at
http://www.circleid.com/article.php?id=805_0_1_0_C/ ), assuming the
ability to sweep ping 100 IPv6 addresses per second on a /64, and
assuming a hit within the first 50%, it would take 2 924 712 086.77
years to find a single host. Of course, the odds go up with more hosts,
however, the time to sweep ping would still be impractical.
Regards,
Mark.
--
The Internet's nature is peer to peer.