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@xxxxxxxxxx] > Sent: Monday, July 02, 2007 4:29 AM > To: paul.hoffman@xxxxxxxx > Cc: ietf@xxxxxxxx > 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@fahrenheit 911 > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf