Security and EIDs

Bob Smart <smart@mel.dit.csiro.au> Tue, 20 October 1992 14:02 UTC

Received: from NRI.RESTON.VA.US by IETF.NRI.Reston.VA.US id aa03220; 20 Oct 92 10:02 EDT
Received: from munnari.OZ.AU by NRI.Reston.VA.US id aa07306; 20 Oct 92 10:03 EDT
Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05137; Tue, 20 Oct 1992 22:55:08 +1000 (from owner-big-internet)
Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19347; Tue, 20 Oct 1992 12:24:43 +1000 (from smart@mel.dit.csiro.au)
Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA08869 (5.65c/IDA-1.4.4/DIT-1.3 for <big-internet@munnari.oz.au>); Tue, 20 Oct 1992 12:24:28 +1000
Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA27094; Tue, 20 Oct 92 12:24:10 EST
Message-Id: <9210200224.AA27094@wanda.mel.dit.CSIRO.AU>
To: big-internet@munnari.oz.au
Subject: Security and EIDs
Date: Tue, 20 Oct 1992 12:24:09 +1000
From: Bob Smart <smart@mel.dit.csiro.au>
Status: O

You folks can't have it both ways on security. On the one hand we
have people saying that separating EIDs from addresses makes it easier
for impersonation attacks (a point Robert Elz made earlier in the year).
On the other hand people are saying that no security mechanisms should
be based on trusting the addresses and/or EIDs in packets. Well if we
don't use the address/EID information in the packet for trust, the 
ability to do impersonation is irrelevant.

The fact of the matter is that a LOT of the operation of TCP/IP networks
depends on trusting the address information in the packets. Suppose
our network is 192.9.200. Suppose I get a packet from 192.9.200.123.
I know my router won't allow a packet with a source address of 192.9.200.x
in from outside. I have physical security on my network. I trust the
security and management of the hosts on my network. So I know that the
packet did come from 192.9.200.123. Like it or not that delicate chain
of logic is used in the day-to-day operation of most LANs on the
Internet. 

Given the IETF requirement that we support existing modes of
operation, I believe we must support this mode of operation for things
like NFS, BOOTP, LPD and many other protocols. We must do this in a
way that is not *less* secure than the existing mechanisms. I believe
I have been careful to keep that in mind in my proposals.

People who think we should introduce IPv7 in the context of a complete
security architecture are in fantasy land. If you want to consider the
technical difficulties you could start with the recent Internet draft
draft-ietf-osids-plan-directory-00.txt (look at the security options
for directory use alone), then get the osisec documentation from
cs.ucl.ac.uk:/osisec. The operational difficulties are even harder.
The politicial difficulties are currently impossible: we can't deploy
this stuff if we can't distribute the software.

I would love to hear if the people planning for a secure Internet
have requirements or preferences for IPv7. I think this request has
been made before with no response. I personally think that security
is an end-to-end matter, and things will work out better if we
split the routing part of the network layer from the end-to-end
part and keep the latter flexible. I hope I'm in tune with John
Curran.

Bob Smart