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

Re: IPSEC WORKING GROUP LAST CALL


Regarding the first point below (data recovery), on a scale of  1-5 for
strongly agree-strongly disagree, I think I would choose 10. Data recovery
is an application issue.  IP is (prior to IPSEC) simply an unreliable
connectionless datagram service.  The two are completely unrelated by
definition.  Unless of course, by data recovery, the contributor means key
escrow, or in plain language - sanctioned eavesdropping, in which case my
response, on a scale of 1-5, is 10,000.  Moreover, the argument would seem
to actually go to the reverse.  If IPSEC were to mandate data recovery, or
key escrow, then the grass roots will simply use something else, or use
application layer encryption to render the "data recovery" mechanism
useless.

Regards,
Mitch Nelson

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: