Its not exactly a surprise, folk seem to place a higher premium on shooting NAT
than anything else. Meanwhile the vast majority of residential broadband access
is behind NAT.
And from a security point I want to see as much NAT as possible. Without NAT we
would be in a much worse situation security wise than we are today. NAT is a
blunt instrument but it shuts down inbound server connects. And that is such a
good thing from the point of view of stopping propagation of network worms.
The situation is even worse when you consider the basis for the inter-ISP
organizations that you might be able to use to drive a transition to IPv6. The
ones that have the capability to drive change are built out around security
issues - spam, phishing. They didn't like NAT because it was a threat to
revenues, they would like to charge for every device in the house. But now they
see it as driving down their security and customer service costs which is much
more important to them.
When people are solving a problem with a blunt instrument the solution is to
give them a better solution to meet their problem. I think I have found one,
default deny infrastructure based on domain centric administration.
The security objective here is to lock down a network tighter than has ever
happened in the past. Every hub, every NIC becomes a policy enforcement point
and no packet moves anywhere in the network unless a policy says it should.
Note here that the rules for the network are not the same as for the
inter-network. The inter-network continues as before.
Default deny is quite straightforward, we could almost do it today with
existing network tools and technologies, the only problem is that the
administration load would be crippling. Every application or network change
would require an administrative change and router updates to be processed and
deployed.
Which brings me to domain centric administration. To support the security
objectives we need a support infrastructure for network administration that
gets us out of the machine code era. Today we don't administer networks, we
administer individual hosts connected to the network. With rare exceptions such
as SNMP we don't have network level abstractions, everything is configured
manually at the level of individual config files.
In breif, give every device the ability to authenticate itself at build time,
define a device description language, push the information out using the DNS
[not multicast, not broadcast, not LDAP even, just plain old DNS plus a
security layer]
draft-hallambaker-Domain_Centric-00
From an IPv6 point of view domain centric administration makes the transition
easy, the day IPv6 service becomes available at the ISP the system just
configures itself to use it without any fuss. Its just like recompiling a 32
bit program to work on a 64 bit machine.
So now lets get back to why NAT today is a good thing.
Most residential systems don't need inbound service requests. So block them.
Its not quite default deny, its much blunter, but it creates real cost
reductions.
From a security point of view the idea that we will ever arrive at a situation
where the endpoints are secure against penetration attacks is nonsense. Not
when the endpoints have ten million lines of code runing (linux) or a hundred
million (vista). We could put every programmer in the world on fixing bugs,
they would generate almost as many as they fixed.
We have to arrive at a network version of Butler Lampson's security reference
monitor, something that is small, lightweight and simple enough to be coded
reliably. We put our best people on coding that component and we we make it
pervasive. A firewall comes close but its not as fine grained as we want.
Default deny allows the same benefit to be achieved without the collateral
damage. Instead of shutting off every inbound service we enable precisely the
services we require to be externally visible. The NAT configuration can be
appropriately enabled at the same time.
-----Original Message-----
From: Jun-ichiro itojun Hagino [mailto:itojun(_at_)itojun(_dot_)org]
Sent: Monday, July 02, 2007 4:29 AM
To: paul(_dot_)hoffman(_at_)vpnc(_dot_)org
Cc: ietf(_at_)ietf(_dot_)org
Subject: draft-ietf-v6ops-natpt-to-historic-00.txt
At 1:56 AM +0900 7/2/07, Jun-ichiro itojun Hagino wrote:
> NAT-PT really needs to be wiped off the face of the earth. It
provides
all of the disadvantages of IPv4+NAT with all of the transition
costs of IPv6. If there is ever any significant penetration of
NAT-PT, then the
pseudo-IPv6 network will not be able to support any
more kinds of
applications than the NATted IPv4 does today.
i tend to agree, but in rfc-index.txt i could not find
the change of
state to "Historic". what happend to very similar (and
much more evil
IMHO) transition technology, SIIT?
<https://datatracker.ietf.org/idtracker/?search_filename=draft-ietf-v6
ops-natpt-to-historic> indicates that the document making
NAT-PT is in
the RFC Editor's queue.
i am not convinced at all with the content of the
draft. if NAT-PT
is to be made historic due to the claims presented in the draft,
all of the NAT related documents have to be made
historic, instead of
informational, since "informational" can be misleading
to people who
try to implement stuff.
the worst of all is RFC3235. and all of the NAT
traversal documents
(RFC3489, RFC3519, RFC3715, RFC3947, RFC4091, RFC4092,
RFC4380) has to
be banned at once.
itojun(_at_)fahrenheit 911
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf