[156116] in North American Network Operators' Group
Re: The End-To-End Internet (was Re: Blocking MX query)
daemon@ATHENA.MIT.EDU (Fred Baker (fred))
Thu Sep 6 17:50:23 2012
From: "Fred Baker (fred)" <fred@cisco.com>
To: Jay Ashworth <jra@baylink.com>
Date: Thu, 6 Sep 2012 21:49:25 +0000
In-Reply-To: <11671130.23144.1346782974846.JavaMail.root@benjamin.baylink.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
It would be really nice if people making statements about the end to end pr=
inciple would talk about the end to end principle.
http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf
The abstract of the paper states the principle:
This paper presents a design principle that helps guide
placement of functions among the modules of a distributed
computer system. The principle, called the end-to-end
argument, suggests that functions placed at low levels of a
system may be redundant or of little value when compared
with the cost of providing them at that low level. Examples
discussed in the paper include bit error recovery, security
using encryption, duplicate message suppression, recovery
from system crashes, and delivery acknowledgement. Low level
mechanisms to support these functions are justified only as
performance enhancements.
One of the authors of the paper has since restated it in a way that is sign=
ificantly less useful, which is that the only place anything intelligent sh=
ould be done in a network is in the end system. If you believe that argumen=
t, then WiFi networks should not retransmit lost packets (and as a result w=
ould become far less useful) and the Internet should not use routing protoc=
ols - it should only use source routing. So, yes, I think the "Rise of the =
Stupid Network" is a very interesting paper and site, but needs to be handl=
ed carefully.
The argument argues for simplicity and transparency; when a function at a l=
ower layer does something an upper layer - not just the application, but an=
y respectively higher and lower layers - it can be difficult to debug the b=
ehavior. However, it is not a hard-and-fast "the network should never do th=
ings that the end system doesn't expect"; the paper makes it clear that the=
re is a trade-off, and if the trade-off makes sense (retransmitting at the =
link layer in addition to the end to end retransmission in the case of WiFi=
) it doesn't preclude the behavior. It merely suggests that one think about=
such things (retransmitting in LAPB turned out to be a bad idea way back w=
hen). Complexities of various types are unavoidable; to quote a fourteenth =
century logician, "a satisfactory syllogism contains no unnecessary complex=
ity".
Yes, I think that stateful network address translation violates the end to =
end principle. But it doesn't violate it because everyone can't talk with e=
veryone directly; it violates it because a change is made in a packet that =
subverts an end system's intent and as a result randomly breaks things (for=
example, an ICMP packet-too-large response has to be specially handled by =
the NAT to make PMTU work). I would argue that a network-imposed policies l=
ike traffic filters violate the end to end principle no more than network-i=
mposed routing (including not-routing) policies do. If you can't get somewh=
ere or a given address isn't instantiated with a host, that's not particula=
rly surprising. What might be surprising and difficult to diagnose would be=
something that sometimes allows packets through and sometimes doesn't with=
out any clear reason.
I suspect everyone on this list will agree that the KISS principle, aka end=
-to-end, is pretty important, and get irritated with vendors (cough) that p=
ush them towards complex solutions. A host directly sending mail to a remot=
e MTA is not automatically a bad actor for any reason related to KISS. Ther=
e are two issues, however, that you might think about. My employer tells me=
that they discard about 98% of email traffic headed to me; a study of my o=
wn email history says that the email from outside that passes that filter a=
nd which is what I expect to receive comes through less than 1000 immediate=
SMTP predecessors to the first Cisco MTA; running the same survey on my ju=
nk folder (which is only 30 days, not 18 years) has about 5000 SMTP predece=
ssors, the 1000 and the 5000 are disjoint sets. So an SMTP connection to a =
remote MTA is not a bad thing automatically, but it raises security eyebrow=
s - and should - because it is similar to how spam and other attacks are tr=
ansmitted. In addition, at least historically, in many cases those MUAs dir=
ectly connecting to remote MTAs try or tried to use them as open relays, an=
d it was difficult for the relay to authenticate random systems. Having an =
MUA give its traffic to a first hop MTA using SSL or some other form of ser=
vice authentication/authorization improves the security of the service. Tha=
t can be overcome using S/MIME, of course, given a global PKI, but DKIM dep=
ends on the premise that the originator has somehow been authenticated and =
shown to be authorized to send email.
On Sep 4, 2012, at 11:22 AM, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Owen DeLong" <owen@delong.com>
>=20
>> I am confused... I don't understand your comment.
>=20
> It is regularly alleged, on this mailing list, that NAT is bad *because i=
t=20
> 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 transacti=
ons.
>=20
> 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 do=
es
> that* (in attempting to send mail directly to a domain's MX server) *from=
=20
> behind a NAT router*, and possibly different ones at different times.
>=20
> I find these conflicting reports very conflicting. Either the end-to-end
> principle *is* the Prime Directive... or it is *not*.
>=20
> Cheers,
> -- jra
> --=20
> Jay R. Ashworth Baylink jra@baylin=
k.com
> Designer The Things I Think RFC=
2100
> Ashworth & Associates http://baylink.pitas.com 2000 Land Rove=
r DII
> St Petersburg FL USA #natog +1 727 647=
1274
>=20
----------------------------------------------------
The ignorance of how to use new knowledge stockpiles exponentially.=20
- Marshall McLuhan
