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

Re[2]: ipsec compression support


Donald,

Thanks for the comments.

>Author:  dee@world.std.com@INTERNET
>Date:    5/5/95  2:01 PM

>}Ipsec currently does not have any "clear header" fields to describe the
>}encryption, integrity, or compression algorithm.  Our approach has been to
>}bundle all of the negotiated attributes of the "security transform" into a
>}single identifier (SPI or SAID) that determines the "security association"
>(SA).
>}
>}The use of compression with encryption needs to be defined as a new security
>}transformation.  These transformations are currently identified in the
>}documentation as a arbitrary string of characters (e.g. DES-CBC-FOO).  It 
might
>}be reasonable to define for your needs a DES-CBC-MD5-LZ77 transformation.
>
>Nope, compression is of the clear data and is totally independent of
>any encryption that might follow.
>

Yes, I believe I agree, but my point was that our current design approach does 
not place any "clear" bits in a header that indicate the type of processing.  
So for transmit processing (esp with compression, encryption):
  - determine the correct Security Association for source and destination
  - use SA to determine the Security Transform and keys to use
             (for example let's assume DES-CBC-LZ77)
  - compress the payload ("clear data")
  - encrypt
  - add header SPI/SAID (aka a "clear header") and IV fields
  - send it ...


>}The working group will soon have to address  in more detail the registration 
of
>}these transforms for use in the IKMP negotiation process.  This will likely
>}yield a large space for new transformation so there will be plenty of room for
>}LZ77.
>}
>}The more difficult issue is whether there should be a "recommended" 
compression
>}algorithm.  A rough first cut at the IPSEC requirements for compression are:
>}
>}The compression algorithm shall:
>}
>}1) work effectively on IP packets.
>
>This is significant since many compression algorithms are optimized
>for long files.


Yes.


>}2) work well combined with a selected encryption algorithm
>
>I can't see how any of the  discussed encryption algorithms could fail
>to work well with any compression algorithm I know about.
>
>}3) not adversely decreases the "strength" of the selected encryption algorithm
>
>This would be really hard to do.  Almost any compression algorithm will
>effectively strengthen almost any strong encryption algorithm in that the
>enemy at least has less cyphertext to play with.

Ok, 2 and 3 above are not very good requirements.  Our "good" security pratices 
already prescribe that the encryption mechanisms should be secure for know 
plaintext attacks.


>}5) be easily and effectively implemented in software.  Software processing 
time
>}   should not be excessive.
>}
>}5) be easily and effectively implemented in hardware to support high speeds
>
>5(4)&5 are unlikley to be problems.

Maybe, but the IBM proposal did indicate the advantages of existing hardware.  
It is also possible to make some very computationaly difficult designs that we 
should try to avoid.  These requirements (4 & 5) really should be criteria by 
which we compare the performance of proposals.


>}6) have well defined and accepted licensing terms
>}
>}It is not a requirement, but it also helps in the process to have openly
>}available software implementations
>



Paul

PS - I will read mail next 5/24