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

[Brian E Carpenter <brc at zurich.ibm.com>]

Tom Petch wrote:
> <inline>
> Tom Petch
>
> ----- Original Message -----
> From: "Iljitsch van Beijnum" <iljitsch at muada.com>
> To: "Hallam-Baker, Phillip" <pbaker at verisign.com>
> Cc: "IETF General Discussion Mailing List" <ietf at ietf.org>
> 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 mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf