[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPv4 Security redux
At 07:29 AM 4/23/93 EST, Tom Benkart wrote:
>Phil, perhaps an approach we should examine is coming up with two
>variants of a single IPSP - orient the "mainstream" variant for
>the high-speed line, but specify in parallel a "header compressed"
>form for low-speed lines. Having both efforts go on in parallel
>should ensure that compression considerations are adequately covered.
>
>Tom Benkart
>Acc Systems
Hmm. An intriguing idea, but it's not clear to me how easy this is.
TCP/IP could be header compressed because many of the fields are either
nonchanging or change in easily predictable ways. Much of the security
protocol, by design, will change in ways that are completely
unpredictable to anyone without the appropriate crypto key (the
authentication field, for example, will appear to be completely random).
While some of the other fields (such as the key ID) are in principle
compressible, the job is complicated by the possibility that the network
can reorder packets. (VJ TCP/IP compression assumes in-sequence delivery
over the path that packets are compressed). Also, VJ compression peeks
at the TCP headers to determine when it should resynchronize the
recieiver; in purely connectionless environments such as UDP/IP or
anything using secure IP, a separate back channel would be required for
this purpose.
Phil