[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 ..."
Mark;
I think we've covered the waterfront on this issue. I think we basically
have
differing views on how much "operational, practical, market-reality" issues
should be covered by IETF documents, and how "true to the vision of the
protocol" the documents should remain.
I think a great outcome for the NAP draft would be to eliminate NAT, and
any perception that NAT was something organizations should *want* to
deploy - as opposed to something they may have *had* to deploy in the
IPv4 world. If maintaining some state in the network for the foreseeable
future - stateful firewalls and application proxies - helps advance that
cause
I think it is a terrific tradeoff.
I'm happy to leave it to the authors to decide how much weight proxy servers
get as part of the operational security model (if any), and how much text
is devoted to it in their document.
Good discussion.
Spence
------------------------
> > 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 proponents 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 existence 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 enforcement 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.