[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC WORKING GROUP LAST CALL
P.S. Regarding the comments in 3 - "breaks the layering model", and
in 4 - "too complex", and in 5 - "incomplete" (as related to deployment)
is there perhaps a ring of truth here?
On Sun, 22 Feb 1998, Alex Alten wrote:
> 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
>
>
References: