Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!princeton!allegra!ulysses!faline!karn
From: karn@faline.UUCP
Newsgroups: comp.dcom.lans,comp.protocols.misc
Subject: Re: OSI-model software
Message-ID: <664@faline.bellcore.com>
Date: Wed, 17-Jun-87 23:23:48 EDT
Article-I.D.: faline.664
Posted: Wed Jun 17 23:23:48 1987
Date-Received: Sat, 20-Jun-87 00:46:45 EDT
References: <223@diab.UUCP> <233@idacrd.UUCP> <526@alliant.UUCP> <1214@botter.cs.vu.nl>
Organization: Bell Communications Research, Inc
Lines: 45
Xref: utgpu comp.dcom.lans:492 comp.protocols.misc:58
Summary: encryption belongs in more than one place

In article <1214@botter.cs.vu.nl>, ast@botter.UUCP writes:
> Encryption.  ISO seems to be totally unable to get its act together.  Other
> than unambiguous statements that encryption does not belong in the session
> layer or physical layer, it seems that all others are possible, although
> lately I have been hearing noises that maybe presentation is "in" again.
> I think spreading it out all over the place is a disaster.  Logically I
> think it belongs in presentation--it deals with "meaning" in some sense.
> In any event, the current situation is a disaster.

I think there are some good reasons for encrypting at more than one
layer.  End-to-end encryption is the most effective way to keep a
message's contents private, especially if you want to use any available
network (e.g., a PDN), since nothing in the network need be trusted.
There is probably something to be said for encrypting anything that the
network doesn't absolutely have to have to do its job, so you might as
well encrypt the transport header as well.  In other words, encrypt
on an end-to-end basis on the interface between L3 and L4.

However, end-to-end encryption doesn't protect you against traffic
volume analysis by someone outside the network monitoring its links, so
encryption on a per-link layer is still necessary. The only remaining
threat then becomes traffic analysis from within the network itself.
This is virtually impossible to prevent since the network must have
readable addresses in order to do its job; about the only thing you can
do is generate lots of garbage traffic to random destinations to spoil
their statistics -- IF you happen to have money to burn (i.e., work for
NSA).

You could go further and build a hierarchy of networks with encryption
in each.  For example, you could build a TCP/IP Internet where the
gateways use X.25 public networks (possibly having internal encryption)
to pass encrypted IP datagrams which themselves contain end-to-end
encrypted TCP data segments. A dishonest subnet could then only analyze
a fraction of the total Internet traffic, and those observations would
be much less precise because of the (hidden) multiplexing and routing
changes going on at the IP layer. It is entirely possible that one of
the unstated reasons for DoD's insistence on datagrams is to allow
"gratuitous rerouting" (i.e., route changing not necessitated by link
failures or congestion). This would be yet another technique to foil
traffic analysis attempts at the lower layers.

So redundant encryption still makes sense, so that the lower the layer,
the less trusted its components have to be.

Phil