Message-Id: <199406020647.AA09887@shark.mel.dit.csiro.au>
To: sipp@sunroof.eng.sun.com
Subject: Re: IPng Directorate meeting in Chicago; possible SIPP changes 
In-Reply-To: Your message of "Tue, 31 May 1994 11:21:31 PDT."
	            <94May31.112133pdt.12171@skylark.parc.xerox.com> 
Date: Thu, 02 Jun 1994 16:47:20 +1000
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bob Smart <smart@mel.dit.csiro.au>

 > We would appreciate your comments on any or all of the above.

Well this was probably intended for the active members of the group, but
anyway:

I think the 16 byte option has the potential to make everyone happy. But
let's divide it into 2 8-byte halves:

 - The top 8 bytes is used by routers except for the last router.

 - The bottom 8 bytes is an end identifier used by the last router. It
   is also globally unique and used as the transport identifier.

We can then arrange the packet so that all the stuff that the key backbone
routers need for routing is grouped together for caching. Since it is 
clearly planned to leave at least 48 bits for the "host" part of the address
this doesn't seem to give up much of the "net" part of the address.

There are lots of ways to generate identifiers and they have been discussed
at length. If there is a need for identifier-based DNS lookups then some
hierarchical allocation is needed. If not then a self-delimiting system
headed by an option number will let people choose any way that suits them.

One option could then be to make it the cryptograhically secure hash of 
the public key for the end system. Then when a packet from a given address
includes an option saying "my public key is ..." you can check it directly
without reference to other authority. Of course the fact that MD5 is
128 bits suggests some doubts that less than 64 bits would be enough to be
cryptographically secure, but remember that the attacker has to do more
than find alternative bits giving the same checksum: they've got to find
an alternative public key giving the same checksum. Given the difficulty
of generating public keys a 48 bit checksum would be plenty. [If your 48 bit
number has been taken then your registration attempt fails and you generate
another one. Even the registration authority doesn't remember which addresses
go with with which checksums: it just keeps a list of registered checksums,
so there is no sensible way to take advantage of a failed registration which
is a very unlikely event anyway.]

Something like this would show that IPng was serious about security.

Bob Smart