On 9/4/2012 2:22 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" <o...@delong.com> > >> I am confused... I don't understand your comment. > > It is regularly alleged, on this mailing list, that NAT is bad *because it > violates the end-to-end principle of the Internet*, where each host is a > full-fledged host, able to connect to any other host to perform transactions. > > We see it now alleged that the opposite is true: that a laptop, say, like > mine, which runs Linux and postfix, and does not require a smarthost to > deliver mail to a remote server *is a bad actor* *precisely because it does > that* (in attempting to send mail directly to a domain's MX server) *from > behind a NAT router*, and possibly different ones at different times. > > I find these conflicting reports very conflicting. Either the end-to-end > principle *is* the Prime Directive... or it is *not*. >
The end-to-end design principle pushes application functions to endpoints instead of placing these functions in the network itself. This principle requires that endpoints be *capable* of creating connections to each other. Network system design must support these connections being initiated by either side - which is where NAT implementations usually fail. There is no requirement that all endpoints be *permitted* to connect to and use any service of any other endpoint. The end-to-end design principle does not require a complete lack of authentication or authorization. I can refuse connections to port 25 on my endpoint (mail server) from hosts that do not conform to my requirements (e.g. those that do not have forward-confirmed reverse DNS) without violating the end-to-end design principle in any way. Thus it is a false chain of conclusions to say that: - end-to-end is violated by restricting connections to/from certain hosts [therefore] - the end-to-end design principle is not important [therefore] - NAT is good ...which I believe is the argument that was being made? ... Ref - http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf > Cheers, > -- jra >