[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Comments on IPSEC work


Dear IPSEC-ers,

I was made aware of the IPSEC effort at the ISSNDSS '94
conference in San Diego. After that I have spent a few hours
browsing through the IPSEC archive retrieved from ftp.ans.net.

Personally, I have been working with IP security for two years
as the leader of a project developing an IP encryption
device based on the SDNS Security Protocol 3. This device
may either act as an end system or as a router with integrated
encryption functions. The primary objective in the project was
to develop a device to be used for secure LAN interconnection.
The results of this work was presented at the ISSNDSS '94.

With this background, I would like to offer my comments on some
of the work and proposed protocols in the IPSEC working group.

1) Comments on the swIPe protocol:

   - It is unclear why the author introduces an additional protocol
     type (the IPPROTO_SWIPE). Maybe the idea behind this was to
     leave the IP input routine unchanged and to add SWIPE as a
     new protocol that IP may include in it's protocol switch for
     higher layer protocols.
     However, the protocol type field of the IP header cannot be
     trusted, so such an implementation architecture would provide
     an intruder with a very easy way of bypassing the securiy
     functions.
     I assume therefore that the "policy engine" of the swIPe prototype
     uses other information (such as src and dst IP address) to decide
     what to do with a received packet.
     Note that it will always be necessary to change the IP input code
     to avoid bypass problems, so I can see no justification for
     introducing the IPPROTO_SWIPE protocol type.

   - The swIPe protocol claims to support a "wide variety" of crypto
     systems. Well, this wide variety actually excludes all stream
     ciphers. If you use a stream-cipher, you will have to carry
     some use-and-discard crypto synchronization per packet, such as
     a random IV or an encrypted random packet encryption key.
     There is no room for this in the swIPe header.

   - The packet sequence number of swIPe introduces a semantical
     problem, since an IP protocol engine does not know which transport
     connection a given datagram belongs to.
     The architecturally clean way to protect against replay is to
     include sequence numbers in higher layer protocols, as these
     will automatically be protected by the integrity mechanisms
     implemented in the IP security protocol. All this talk about
     sequence numbering in IPSP is, in my opinion, approximately
     nonsense.

   - I don't like the placement of the authenticator as a part of
     the protocol header. Place it at the end of the packet in stead,
     like in SP3 and NLSP-CL. This will ease the cryptographic
     processing of the PDU in many cases.

   - A good thing about swIPe is that it its header is word aligned.
     When we implemented SP3, we discovered that unless the header
     of the transport layer protocol (UDP of TCP) started on a 32-bit
     boundary, the OS panic'ed with "bus error" due to alignment
     problems (This was a Sparcstation 2 running SunOS 4.1.2). Of
     course, there are workarounds, but word alignment is a good idea
     and will be applauded by implementors.

2)   Comments on key management:

     In our prototype, we solved the problem of key mangament in
     a way that I have not seen among the suggestions in the ipsec
     mailing list.
     We simply defined an enterprise  specific MIB branch for
     encryption keys, the
     data type of the key information being OPAQUE as seen from
     the SNMP agent, who passes the value-part of a variable binding
     transparently to a hardware crypto module (HCM).
     The value-part of the variable binding represent a packet
     as defined by the HCM interface for setting keys, erasing keys
     etc. As such, the SNMP protocol was only used as a "bucket"
     protocol for exchange of general purpose data. Of course the
     packet format and "protocol" for exchanging data between
     the HCM and the host machine must be designed to counter
     threats like key disclosure, key corruption, replay etc.
     As an example, this may be an ANXI X9.17 interface.
     It actually works fine, although it admittedly has some
     weaknesses like limited opportunities of error reports etc.

3)   Comment on the need for a new layer 3 security protocol:

     As Paul Lambert said at the ISSNDSS '94 no flaws or errors
     has been detected that makes SP3 unsuitable or inappropriate
     for use as a security protocol for IP. Also, there are several
     commercial network encryption products available using SP3.
     SP3 therefore seems a very good starting  point for SPIP, may
     be it is enough to do write an "Internet SP3 profile" e. g. to
     ensure word alignment, or maybe it's necessary to change the
     semantics of the KeyID field to something like an SAID with the
     capability of optionally carrying crypto sync.
     The first NLSP-CL draft was generated by doing :s/SP3/NLSP-CL/g
     on the SP3 specification document. Unfortunately, the
     standardization process did not stop with that.

4)   Question on the IToR flag:

     I would like to have a rather detailed explanation of the use
     of the Initiator-ro-reponder flag. I have never understood
     it's use, nor the "reflection" threat that I have seen
     mentioned various places. In our "trusted router" prototype
     we ignore the IToR flag completely.

5)   The above comments are my personal views, and do not necessary
     conform to those of my company.

Regards,

Paal Hoff,
Norwegian Telecom Research.

e-mail:  pal.hoff@tf.tele.no
X.400:   g=pal;s=hoff;o=tf;p=tele;a=telemax;c=no
phone:   +47 63 80 93 36
fax:     +47 63 81 00 76
Follow-Ups: