John, I completely agree with you here, when I said $50 I meant $50 including the cost of administration. If the user has to do anything more than plug the box in its going to cost a lot more than $50. If no users were stupid and no users were criminals and all programmers were competent there would be absolutely no need for any security technology at all. It took ten years to convince enough people that there were enough stupid, criminal and incompetent people that they had to think about security before deploying stuff like cookies, javascript, BASIC authentication and so on. You were in the room when we had to convince MarcA that integrity was a security inssue they had to take notice of. That was 1994, it took till 2004 till professional Internet crime was accepted as a real phenomenon that designers needed to consider seriously. Lets look for commonality here. I think we can all agree on the following: 1) NAT workarrounds are bad, they are layer violations that other network applications end up having to cope with. 2) Applications that assume end to end consistency of network addresses violate the layering principle and are therefore bad. 3) Network administration has real costs and is too complicated as far as most users are concerned. I agree that today stamping out cookie cutter networks in NET 10.x.x.x and gating them to the Internet via NAT is the way to go. Domain Centric Administration would allow us to meet that set of requirements better. The draft is not yet in the repository, but the principles are pretty straightforward: 1) It is a directory driven network administration approach 1a) The directory is DNS. The SRV record is used for service discovery, prefixed TXT records for protocol policy statements, XPTR to allow a wildcard effect. 1b) The security layer is DNSSEC or possibly TSIG combined with a lightweight keying mechanism 1c) There are no more reserved port numbers. All discovery takes place via SRV. 1d) We don't use broadcast or multicast, just plain DNS. 1e) DHCP is used to obtain an IP address and the DNS prefix for the local network. A given machine will use the IP address specified but may override the domain name assignment. 2) All devices have built in authentication capability 2a) This follows the DOCSIS 2.0 cable modem spec, bind a cheap device cert into the device during manufacture. This allows the MAC/EUI address to be used as an authenticated identifier 3) All devices and services have the ability to describe their functions and requirements 3a) If Mr Coffee says it needs NTP service and this is allowed by the local network policy it can send/receive NTP packets, otherwise it can't. And even if it is allowed NTP service this might well be rate limited. The idea here is to design a system that offers consumer level ease of use while meeting an enterprise pain point. Schemes such as UPnP failled in my view because they never got vendor buy in which was in turn because consumers don't write RFPs and the schemes suggested did not offer real value to enterprises that do write RFPs. In order to get deployment a scheme needs to meet an enterprise pain point. In this scheme I am aiming to address both the security pain point and the cost of administration pain point. > -----Original Message----- > From: John C Klensin [mailto:john-ietf@xxxxxxx] > Sent: Monday, July 02, 2007 2:06 PM > To: Jeffrey Hutzelman > Cc: ietf@xxxxxxxx > Subject: Re: Domain Centric Administration, RE: > draft-ietf-v6ops-natpt-to-historic-00.txt > > > > --On Monday, 02 July, 2007 13:06 -0400 Jeffrey Hutzelman > <jhutz@xxxxxxx> wrote: > > >... > > That is _not_ because NAT makes the network more secure - > it doesn't. > > It's because most of the people buying those boxes "need" > NAT because > >their ISP's won't give them more than one address, or at > least won't > >do so for a reasonable price. Fix _that_ problem, and you'll start > >seeing boxes that provide security and flexibility without needing > >NAT. > > Jeff, > > I completely agree with your basic comment, and with your > comment above FUD. However, the problem is not _only_ "one > address only" policies as I and others have pointed out. In > particular... > > (1) For the ISP selling a low-end service, having all user > LANs with the same configuration (or being able to tell users > with different configurations that they are on their own) > considerably reduces support costs. Since, at the low > [pricing] end, a single call can cancel out several months of > profits, minimizing customer support costs and calls can be > very significant. > > (2) While DHCP could, in principle, be used to deliver an > address range to a router for use on the LAN behind it, I > know of no devices, especially low-end devices, that support > such a service. > > (3) If a user is given a small pool of public addresses (say the > /28 that is fairly typical for SOHO "business" services), and > has to use that pool for both the external (WAN-side) address > on the router and for the LAN-side, setting up the router > suddenly becomes a job for experts, with some very specific > routing requirements. For devices costing under $200 (much > less $50), I know of no vendors or ISPs who are willing to > offer support and > walk users through this process. Maybe I just haven't looked > hard enough, of course. > > Of course, almost none of the issues above are likely to go > away, or even get better, with IPv6... unless we make some > improvements elsewhere. And none of them make NAT a good idea, > just a "solution" that won't easily go away unless we have > plausible alternatives for _all_ of its purported advantages, > not just the address space one. > > john > > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf