[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 ..."
On Sun, 20 Mar 2005 18:08:35 -0800
"John Spence, CCSI, CCNA, CISSP" <jspence@native6.com> wrote:
>
> 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.
>
I agree that if there is demand, they will be created. I suppose my
position tends to be that some technologies shouldn't be
encouraged, and going into detail in an RFC tends to be encouraging
them.
I think a lot of the time, vendors implement things according to RFCs,
which is fine, and then customers of those vendors then just buy the
product because it states compliance with a list of RFCs, without
reading them. Sadly, that means that any limitations or disadvantages
identified in the RFCs aren't known by the people who probably most need
to be aware of them.
NAT is a good example I think. Even the actual NAT RFCs list a number of
limitations, yet most NAT propopents aren't aware of them. I start to
wonder whether publishing the NAT RFCs was a good idea in the first
place, as I think a lot of people just use the existance of an RFC on
the technology as a technology blessing !
> > 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.
>
True. My example is only really to show how easy network topology based
security mechanisms are easy and cheap to violate by fairly "ordinary"
end users.
> 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.
>
I certainly agree that will be the case for IPv4. I wonder whether that
needs to be the case with IPv6 ? The introduction of IPv6 could be an
opportunity to not only deploy an improved network layer technology, but
also an opportunity to change the mindset on some of these common IPv4
technologies.
> > 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.
>
I think we do. My position on things such as NAT and proxy servers is
based on having my fingers burnt a few times by, more broadly, state in
the network. I suppose I'm looking to identify opportunities where, in
the future, those problems can be avoided, rather than them having to be remedied.
I'm hoping that IPv6 will provide those opportunities. That's why I'd
like to discourage "legacy" IPv4 technologies in IPv6 if it is possible.
> 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.
Is it really ? I tend to read the emphasis on topology hiding in the
draft to be more that pro-NAT proponents consider it to be important,
and the draft is showing how IPv6 can achieve the same levels of
topology hiding. I don't necessarily think that the emphasis is stating
that topology hiding is actually important or that important.
I tend to see this draft as a "rebuttal" document. There are a number of
mechanisms in IPv4 that some IPv4 users consider important, such as NAT,
and therefore think that they should be just blindly implemented in IPv6
for the same reasons. I think this draft says, "there is no need to, and
here is why".
Regards,
Mark.
--
The Internet's nature is peer to peer.