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

Re: IPSEC WORKING GROUP LAST CALL

IPSEC WG,

These are my main technical criticisms of the current set of IPSEC 
documents.

1. No data recovery of an encrypted IP datagram payload.

   Regardless of the merits of the design by not supporting this 
   requirement it will probably kill IPSEC as a viable Internet 
   standard.


2. Interoperability requirement not met.

   To ensure interoperability only one cryptographic mechanism should 
   specified, and no others should be allowed.  The current proposal
   allows an unlimited variety to be used, it seems primarily to allow 
   the standard to scale cryptographic strength upwards.  The requirement 
   for DES-CBC to be always implemented cannot be met because objection
   #1 cannot be met with it.  Probably RC4 with 40b keys will become 
   the de facto interoperable mechanism (this has happened to SSL).
   

3. IPSEC does not properly fit with the IP routing model.

   It force fits the concept of a security session (SA) onto the IP 
   datagram routing model.  Certainy the concept of a user id does 
   not fit the IP address model.  The requirement that AH must know 
   about the IP header structure breaks the general rule of protocol 
   layering.


4. The design is too complex

   This design seems to have been driven primarily by the following.

   A. The desire to side-step export restrictions if necessary.

      This has caused two protocols, AH & ESP, to be specified.
      If #1 is properly satisfied then AH can be eliminated.

   B. The desire to use a proven cipher, i.e. DES.

      This decision has had a profound impact on the design.  Because
      DES is slow, it has forced encryption & decryption to the edge
      hosts, requiring the SA construct to allow the packets to traverse
      intervening routers.  This slowness also contributed to the 
      decision to create AH.  Choosing it has forced the need to handle pad
      & IV bytes within the IP payload, increasing protocol stack complexity 
      when handling the mapping between clear and encrypted payloads.  There
      are many excellent high performance ciphers available many of them do 
      not require IV's or pad bytes.  Many of these can be proved to be very 
      secure, often in a manner obvious to most competent engineers.

   C. The desire to use a public key algorithm.

      This decision has also had an impact on the design.  Because PK is 
      so slow this has also contributed to the use of the SA construct
      instead of other methods which could more closely match how
      IP routing really works.  It makes the management of trust more
      difficult, for example deleting untrustworthy hosts in a timely 
      manner.
   
   D. The desire to distribute policy storage and enforcement.

      By distributing policy storage and enforcement across all the 
      participating hosts and routers it has made it almost impossible 
      to scale this design to very large numbers.


5. The design is incomplete

   A. Auditing needs to be completed.  At the very least what policy events 
      or queries must be specified that can trigger audits.  Also for 
      interoperability reasons, audit record formats should be specified.

   B. The trust model needs to be worked out more completely.  How does the
      secure IP network first get established?  How are nodes added or 
      deleted?  How does a corporate/organization need for controlling
      its own security get reconciled with the need for global 
      Internet interoperability?

- Alex
--
Alex Alten
Andrade@Netcom.Com
P.O. Box 11406
Pleasanton, CA  94588  USA
(510) 417-0159
Follow-Ups: References: