Subject: draft-vandevelde-v6ops-nap-01.txt - "maybe add a bit more on proxy servers ..."

From: "John Spence, CCSI, CCNA, CISSP" <[email-masked]>
Date: Wed, 16 Mar 2005 19:21:38 -0800

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.

A realistic model for an enterprise might be:

1) Give internal-use only devices ULA addresses - no individual host or
topology information leaks to the public network

2) Give clients that only need "commodity" public network access (via HTTP
or FTP or other proxy-friendly applications) also get ULA addresses - again
no host (except the proxy servers themselves) or topology information
(except the proxy server subnet) leaks to the Internet.  This should be -
especially in the near to mid-term - the bulk of the Internet traffic.

3) Give servers and clients needing peer-to-peer capability routable
addresses, and use one of the mechanisms proposed in the document to provide
host and topology hiding.

This strategy strikes a balance between providing true peer-to-peer
capability for hosts with address and topology hiding for most applications
- it reduces the number of nodes that need to use mobileIP or host route
injection mechanisms in order to protect the enterprise.

The draft touches on proxy servers in 2.4.  Perhaps an expanded discussion
of the benefits of proxy services would be appropriate in 5.1 - the case
study for medium and large private networks.

John Spence
----------------------------------------------------
John Spence, Native6, Inc.
IPv6 Training and Consulting
[email-masked]
www.native6.com
----------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Fri, 18 Mar 2005 17:55:22 +1030

Hi John,

On Wed, 16 Mar 2005 19:21:38 -0800
"John Spence, CCSI, CCNA, CISSP" <[email-masked]> wrote:

> <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.

---

From: Baker Fred <[email-masked]>
Date: Fri, 18 Mar 2005 02:38:25 -0500

On Mar 18, 2005, at 2:25 AM, Mark Smith wrote:
> Tony Hain pointed this out a while back on the IPv6 mailing list. For 
> example, (and I've explored this a bit more at 
> 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.

I don't know why people bring that fact up. It is true, but the fact 
that it is true means the problem will be solved another way. I'll bet 
it is done by letter-bombs.

---

From: Mark Smith <[email-masked]>
Date: Fri, 18 Mar 2005 18:27:18 +1030

Hi Fred,

On Fri, 18 Mar 2005 02:38:25 -0500

> it is done by letter-bombs.

Admittedly I don't exactly know what you're refering to with
"letter-bombs", however, I'll guess you're describing using other
techniques to identify devices, such as emails with URLs, with the web
server then recording source IPv6 addresses. Am I correct ?

If I am correct, I completely agree. I consider hiding devices to be a
useful defence mechanism, however, it certainly shouldn't be the only
one. Unfortunately, a lot of pro-NAT people, including those who think
NAT should be implemented in IPv6 because of that property, seem to
consider it the best thing since sliced bread, and talk about it like it
is the "only" security mechanism that is needed. Social engineering via
emails with enclosed URLs, or malware attached to software, are far more
bigger and common threats today, and of course, IPv4 + NAT or IPv6 by
itself won't (and I'm pretty sure will never) be effective against
either of them, or any other attacks that socially engineer the user.

I only bring it up to show that using NAT-style or middleware topology
hiding techniques probably isn't necessary in IPv6, due to the huge
effort involved in sweep pinging a /64. Blocking incoming pings, or
outgoing ICMP unreachables/echo-replies etc. will be effective enough
for those who want further protection than what the huge address space
of IPv6 inherently provides.

Regards,
Mark.

--

---

From: Pekka Savola <[email-masked]>
Date: Fri, 18 Mar 2005 10:32:43 +0200 (EET)

> are worth avoiding for the same reason NAT is.
[...]

Personally, I have to agree with John Spence here, I think.  While 
proxys are not nice from the architectural perspective, they're the 
lesser of the evils in some sense.  If the users need to solve a 
problem (e.g., internal addressing stability using ULAs, ...), they're 
going to do it somehow in any case.  It's just the question whether 
they use NAT, NAT-PT, proxies, or whatever for the task.

At least from that list, proxies look the least of the evils..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Mar 2005 11:19:25 +0100

> are worth avoiding for the same reason NAT is.

RFC 2775 and RFC 3234 addressed these issues, I believe. While I wouldn't
be as negative as that about proxies, I do think that it would divert
from the main argument in the NAP draft if we expanded that topic.

    Brian

---

From: "EricLKlein" <[email-masked]>
Date: Fri, 18 Mar 2005 13:37:46 +0200

Mark Smith wrote
> however, the time to sweep ping would still be impractical.

This might be true in theory, but in practice it is usually not. In my 
experience you can scan the first 20 IP addresses in a subnet and you are 
likely to get at least 5 to 10 hits. This is not inherent in the protocol, 
but tends to be part of human nature. Network Admins tend (in an enterprise 
setting) to like to number things sequentially as it makes it easier for 
them to maintain the address pool and to monitor hardware. So unless they 
work 100% with DHCP and it is set to random, there will be many fixed 
devices (printers, application servers, etc) that reside in that first 20 
addresses.

It is like cash machine pin numbers, people tend to make things easier for 
themselves. So if you know the person you can usually guess the pin by their 
or someone that they care about's birthday.

In general, people will be lazy and do what is easiest for them.

Eric

---

From: Baker Fred <[email-masked]>
Date: Fri, 18 Mar 2005 06:58:31 -0500

Multicast in various forms. The most useful ones would be the All-Nodes 
Multicast Address (link-local) and the All-Routers Multicast Address 
(site-local).

In IPv4, a simple letter-bomb is subnet broadcast. If you know or think 
that 123.45.67.0/24 is a subnet in a company, pinging 123.45.67.255 
might very well get you an ICMP Echo Response from each host on that 
LAN. In IPv6, pinging any multicast address should get you an ICMPv6 
Echo Response from each host in the multicast group. The pinging 
All-Routers should get you a list of the routers in a network, and 
therefore a list of the transit subnets in a network (but not 
necessarily the edge LANs that have only one router on them). 
Subnet-router anycast address will certainly find a router in your 
subnet, and (rather than arping for each of your neighbors as is 
currently done by viruses), pinging the All-Nodes Multicast Address 
should get you an echo response from every node on your local LAN. 
Solicited-Node Multicast also gives you some sweeping capability, 
albeit only on your local lan.

So the counterpart of today's IPv4 virus that sweeps its local LAN is a 
virus that sends two pings, one to All-Nodes and one to All-Routers. 
The echo responses give the application information about the network.

---

From: Mark Smith <[email-masked]>
Date: Sat, 19 Mar 2005 15:10:11 +1030

Hi Fred,

On Fri, 18 Mar 2005 06:58:31 -0500

> Multicast Address (link-local) and the All-Routers Multicast Address 

Oh, OK, the good old "broadcast ping", using m/c in IPv6. I don't think
I've heard of them being called "letter-bombs" before. 

> albeit only on your local lan.

It's a bit of a surprise to me that the offlink sourced methods you've
described would work in IPv6, because I've assumed that as directed
broadcast style techniques had been deprecated in IPv4, they also
wouldn't be available in IPv6. It seems that isn't the case. Based on my
assumption, unicast sweep pinging seemed to be the only possible way to
find remote hosts.

Is there some mechanism in IPv6 that would allow selective responses to
multicast ICMPv6 echo requests, somehow based on the source address or a
combination of the source address and multicast scope ? For example, an
echo-reply to a multicast echo-request would only be sent if the scope
of the destination multicast address was site, and the source IPv6
address was a member of the same site or possibly the source address as
the same /48 prefix as one of the unicast addresses assigned to one of
the interfaces on the possibly responding host.

I've had a look at the ICMPv6 RFC, the section on Echo-requests/replys
doesn't mention any selective response mechanisms. I'll start looking at
some others, it will also help me brush up on IPv6 details again. If
there are any other pointers to RFCs covering this area, I'd appreciate it.

> The echo responses give the application information about the network.

I'd think they'd be quite common, as it seems pretty easy today to get
an user to install software they don't know about behind their NAT box
or proxy server.

Thanks,
Mark.

--

---

From: Mark Smith <[email-masked]>
Date: Sat, 19 Mar 2005 15:20:09 +1030

Hi Eric,

On Fri, 18 Mar 2005 13:37:46 +0200

> devices (printers, application servers, etc) that reside in that first 20 

I'd agree in IPv4 that is common. In IPv6, I'd suggest less so, although
I am assuming that the most common address allocation method would be
based on EUI-64s, making end node addresses would be far less
predictable. If that is still too predictable, I've understood that
enabling Privacy Extensions should elminate all predictability.

Of course, if people implement stateful addressing, then I would expect
the sort of allocation ordering you're describing. That may be likely in
enterprises, and "easy of topology discovery" should possibly be
something enterprises will need to keep in mind as a risk if they choose
to implement stateful addressing.

Regards,
Mark.

--

---

From: Baker Fred <[email-masked]>
Date: Sat, 19 Mar 2005 09:12:23 -0800

We're wandering a bit far afield from the original thread, so I changed 
the thread subject.

Here's another one. Viruses today scan one's address book and do 
interesting things. Imagine a virus that scans the SMTP headers on your 
incoming mail and learns the names (which will translate to a current 
address) and the address (the one that was in use at the time of the 
transmission) of the MUAs and MTAs en route?

If a virus can find one host on a remote LAN and infect it, that host 
can do a link-local ping to all-hosts.

My point in this is that I find the discussion of IPv6 security a 
little self-congratulatory...

---

From: Jeroen Massar <[email-masked]>
Date: Sat, 19 Mar 2005 18:23:50 +0100

>can do a link-local ping to all-hosts.

Or use Samba to find out all the hosts in that domain and all the
domains and thus all the hosts in a company, worldwide...
And of course many many many many other methods.

IP (both IPv4 and IPv6) are about addressing and making computers (and
other things :) able to talk to each other end-to-end.

IP is *not* about making computers *not* talk to each other.

That this indeed has the side effect that some malicious operations are
also able to talk, too bad -> use a firewall *and* configure that one
correctly, oh and of course don't forget to keep your OS + software up
to date ;)

Greets,
 Jeroen

---

From: "John Spence, CCSI, CCNA, CISSP" <[email-masked]>
Date: Sun, 20 Mar 2005 18:08:35 -0800

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 
> 
> He has a number of other insightful papers on his "ISP 
> Column" web page at
> 
> 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.
 
> 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.

---

From: Mark Smith <[email-masked]>
Date: Mon, 21 Mar 2005 13:37:17 +1030

On Sun, 20 Mar 2005 18:08:35 -0800

> How does this sound Yurie?  Demonstrating the brand we wish to portray?

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 !

> 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.

> 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.

> 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.

> 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.

--

---

From: Baker Fred <[email-masked]>
Date: Mon, 21 Mar 2005 00:13:00 -0800

On Mar 20, 2005, at 7:07 PM, Mark Smith wrote:
> I agree that if there is demand, [proxies and stateful firewalls] 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.

Actually, that isn't the case. The IETF documents the good, the bad, 
and the ugly, and the purpose is often community memory. For an 
example, take a look at Transaction TCP (RFC 1644) and the rather large 
number of experimental and historical RFCs. "Experimental" doesn't mean 
"bad", but it also doesn't mean "thought well of" either.

And something that can be immensely helpful is documenting the purpose 
being served, the options available for serving it, and giving advice 
on how to do that in a way that imposes the least damage. Saying 
nothing gives no guidance; saying "stateful firewalls have <this> 
limiting characteristics which can be mitigated if <that> attribute is 
a feature of it and is used in a certain way" can be a very helpful 
thing.

Instead of saying "As a purist I don't like this", I think we're all 
better off if we can describe how to meet network requirements in a way 
that minimizes damage to the architecture - which IIRC is what the NAP 
document is all about.

---

From: "John Spence, CCSI, CCNA, CISSP" <[email-masked]>
Date: Mon, 21 Mar 2005 09:25:07 -0800

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

------------------------

> > > 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.
> > 
> > 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
> Column" web 
> > > page at
> > > All the policy mechanisms you mention really are best done on the 
> > > end host itself. There are two main reasons. Firstly, 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.
> > > surreptitiously or not. I first came across this idea in Steve 
> > 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.
> 
>   
> > > 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 
> assuming the 
> > 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.
> 
> -- 
>