[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 ..."
How does this sound Yurie? Demonstrating the brand we wish to portray?
----------------------------
Mark, et. al - my comments below, interleaved.
> Unfortunately, proxies 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. Proxies are worth avoiding for
> the same reason NAT is.
Proxies absolutely break end-to-end. As does NAT. As do stateful
firewalls.
If NAT can be eliminated, that would be a great step in the right direction.
As
for stateful firewalls, and I would argue application proxies, companies
will
continue to deploy these for a number of reasons. These are internal
risk/reward
decisions for local administrators to make - not a good place for the IETF
to try
to enforce policy. Believe me, if there is a demand for IPv6-capably proxy
servers,
the market will provide them.
> Geoff Huston wrote an excellent paper describing the issues
> that "middleware" (the generic name for things such as
> proxies) 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 surreptitiously or not. I first came
> across this idea in Steve Bellovin's paper, "Distributed Firewalls",
The example you give - where someone puts an AP onto the enterprise network
-
upstream firewalls and proxies still work fine. If the firewall is
configured to only
allow outbound access for tcp80 traffic from known proxy servers, clients on
the
AP networks will not be able to bypass the proxies. The problem in this
example is
unauthorized access to the internal enterprise network - not the ability to
defeat
the edge device security measures of firewalls and proxies.
And I agree that distributed tools - like firewalls and policy enforcement
are the
way to go, and I look forward to their ongoing development. But for awhile,
stateful
edge firewalls and proxy servers have a role to play.
> 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 maturity 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 proxies, sooner rather than later.
Perhaps we agree more than disagree. As a pragmatist, and a deployment
engineer, I am interested in practical matters - including near-term issues.
For me, the NAP draft is about saying "here is a collection of tools and
techniques
that allow the elimination of NAT while maintaining a secure network".
Right now, I
think proxies should be one of the tools. And considering how much Internet
traffic
is proxyable, and how prevalent proxy-based value-add tools are in
enterprises today,
I think it warrants more emphasis.
> 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.
Sure. Nonetheless, proxy servers provide host ID and network topology
hiding, and should be quick and easy to deploy for IPv6 networks, and can
serve a majority of Internet traffic, while allowing the security team to
conduct
other policy enformcement and packet/session analysis.
Plus, the draft does spent quite bit of time talking about topology hiding
and
how it can be done for IPv6 networks - so I believe the draft is already
saying that
topology hiding *is* important.