e2e [Re: Port numbers andIPv6(was: I-D ACTION:draft-klensin-iana-reg-policy-00.txt)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tom Petch wrote:
<inline>
Tom Petch

----- Original Message -----
From: "Iljitsch van Beijnum" <iljitsch@xxxxxxxxx>
To: "Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>
Cc: "IETF General Discussion Mailing List" <ietf@xxxxxxxx>
Sent: Wednesday, July 20, 2005 12:36 AM
Subject: Re: Port numbers andIPv6(was: I-D
ACTION:draft-klensin-iana-reg-policy-00.txt)



On 19-jul-2005, at 23:35, Hallam-Baker, Phillip wrote:


Host and application security are not the job of the network.

They are the job of the network interfaces. The gateway between a
network and the internetwork should be closely controlled and guarded.

You may want to read up on the end-to-end principle (or argument, if
you prefer). It's not the "network interface-to-network interface"
principle.

In other words: if the endpoints in the communication already do
something, duplicating that same function in the middle as well is
superfluous and usually harmful.



Mmmm so if I am doing error correction in the end hosts, and somewhere along the
way is a highly error prone satellite lnk, then I should let the hosts correct
all the satellite-created errors?  I don't think that that is the way it is
done.

That isn't quite the point.

The end systems can't assume error correction en route; if they require
correct data, they must apply e2e error correction of some kind. Certainly
a TCP retransmission is not optimal if there happens to be a satellite
hop - so nobody objects to satellite hops performing aggressive FEC.
But this doesn't let the end systems off the hook.


Likewise, if my sensitive data mostly traverses hard to penetrate links (fibre)
but just somewhere uses a vulnerable one (wireless), then I just use application
level encryption, as opposed to adding link encryption over the wireless link in
addition?  Again, I think not.

Again, the end systems cannot safely assume anything. If the hypothetical encrypted
wireless link goes down, and is backed up by a piece of telelphone wire, e2e
protection is the only answer.

End-to-end is not always best but I am not sure which law of network engineering
points out the exceptions.  Probably something to do with different levels of
entropy along the way.

We are after good enough, not best. I think that the point of the Saltzer et al
paper is that e2e is always good enough.

I have to agree that e2e cannot create network level QoS that isn't available -
if the best path available can't offer the desired QoS, no end system magic can
achieve that QoS. But it can at least make the best use of the QoS available,
e.g. by reducing a streaming data rate to avoid random loss.

In answer to another comment, it's perfectly true that some services today are
provided by systems intermediate between the end users concerned; these are sometimes
referred to as services in the network. But that really doesn't change the point
of Saltzer et al. The boxes providing those services are end systems as far as
Level 3 is concerned.

   Brian


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]