[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Another "open" implementation, with some similarities to swIPe
I've recently finished an IP layer security protocol prototype that has
some similarities to swIPe (the similarities are more intentional than
not). The prototype was developed on a BSD/386 1.1 PC and is currently
being ported to a BSD4.4-lite kernel. Only the Host to Host mode is
implemented at this point. The packet format was developed with the
following in mind.
o 64 bit word header alignmnet
o fixed-length fields
o minimal overhead
o IP like proto field functionality
o no sequence numbers
The packet format follows:
Host to Host Mode:
1 2 3
0123 4567 8901 2345 6789 0123 4567 8901
+----+----+---------+-------------------+ ------------
|Ver |IHL | TOS | Total Length |
+-------------------+--+----------------+
| Identifier |Fl| Frag. Offset |
+---------+---------+-------------------+
| TTL | Protocol| Header Checksum | IPv4
| | (52) | | Header
+---------+---------+-------------------+
| Source Address |
+---------------------------------------+
| Destination Address |
+---------------------------------------+
| Options + Padding |
+---------+----+----+-------------------+ -----------
| Prot |Ver | Fl | Length |
+---------+----+----+-------------------+ SDT PDU
| SAID | Reserved | Header
+-------------------+-------------------+ -----------
| Alg_Param + D_Length |
+-------------------+-------------------+ Protected
| | Octet
| Data | String
+---------------------------------------+
| Pad + ICV |
+---------------------------------------+ -----------
Host to Router & Router to Router Mode:
1 2 3
0123 4567 8901 2345 6789 0123 4567 8901
+----+----+---------+-------------------+ ------------
|Ver |IHL | TOS | Total Length |
+-------------------+--+----------------+
| Identifier |Fl| Frag. Offset |
+---------+---------+-------------------+
| TTL | Protocol| Header Checksum | IPv4
| | (52) | | Header
+---------+---------+-------------------+
| Source Address |
+---------------------------------------+
| Destination Address |
+---------------------------------------+
| Options + Padding |
+---------+----+----+-------------------+ -----------
| Prot(94)|Ver | Fl | Length |
+---------+----+----+-------------------+ SDT PDU
| SAID | Reserved | Header
+-------------------+-------------------+ -----------
| Alg_Param + D_Length |
+----+----+---------+-------------------+
|Ver |IHL | TOS | Total Length |
+-------------------+--+----------------+
| Identifier |Fl| Frag. Offset |
+---------+---------+-------------------+
| TTL | Proto | Header Checksum | Protected
| | | | Octet
+---------+---------+-------------------+ String
| Source Address |
+---------------------------------------+
| Destination Address |
+---------------------------------------+
| Options + Padding |
+---------------------------------------+
| |
| Data |
+---------------------------------------+
| Pad + ICV |
+---------------------------------------+ -----------
There are some differences between this and swIPe, but most of them
are for efficiency sake, not security. I chose not to include
sequence numbers because of various off-line discussions and
the negative response at the Feb. ISOC meeting. Having the ICV
in the tail of the packet may have some advantages, but that
isn't clear to me at this point. I also don't see any reason to
include the entire IPv4 header in the security envelope when
the security is applied Host to Host. I do think that a two-byte
SAID is long enough until a better definition on how it will be
used in the future is available. I have included a version number
and two-bytes of reserved that will allow for growth.
Integrity is applied from the Algorithm Parameters to the end of
the Data. Encryption is applied over the Data Length (D_Length)
to the end of the packet (including the ICV).
The prototype runs straight over IPv4 and has "manual" key managment
built into the kernel. Access to the key management information
is via a socket. Currently I only have DES CBC for both integrity
and confidentiality, but I am getting very reasonable performance
(operational using ftp, ping, telnet, etc., no actual performance-specific
testing at this point).
I'd be more than happy to provide anyone (US-only because of the DES
and export laws), with a copy of this and instructions on how to
install and operate. I am hesitant to widely distribute the prototype,
because it is still "under development". I would like to add other
algorithms to the code, implement the Router Mode, and add a
diffie-helman exchange to the key-managment code. The Proto number,
52, is registered in case anyone else would like to implement this
protocol and do some testing. For more information on this protocol,
the details can be found in the internet draft entitled INLSP for
TUBA. A revised version of this draft is forthcoming.
Rob G.
glenn@osi.ncsl.nist.gov