RE: Domain Centric Administration, RE: draft-ietf-v6ops-natpt-to-histori

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(_at_)jck(_dot_)com] 
> Sent: Monday, July 02, 2007 2:06 PM
> To: Jeffrey Hutzelman
> Cc: ietf(_at_)ietf(_dot_)org
> 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(_at_)cmu(_dot_)edu> 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(_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