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
- Security and EIDs Bob Smart
- Re: Security and EIDs Frank Kastenholz
- Re: Security and EIDs Christian Huitema
- Re: Security and EIDs Dennis Ferguson
- Re: Security and EIDs Noel Chiappa
- Re: Security and EIDs Noel Chiappa