Re: draft-ietf-ippcp-lzs-01.txt for comments

[Avram Shacham <[e-mail]>]

Robert,

Your draft looks good. Please see my comments in the document.

Regards,
avram

At 03:30 PM 11/14/97 -0800, Robert Friend wrote:
>Abstract
>
>   This document describes a IP compression method based on the LZS
                              ^^
Is 'IP' necessary?

<snip>

>1.2 Background of LZS Compression
>
>   Starting with a sliding window compression history, similar to [LZ1],
>   Hi/fn developed a new, enhanced compression algorithm identified as
>   LZS. The LZS algorithm is optimized to compress all file types as
                                                    ^^^^^^^^^^^^^^
?

>   efficiently as possible.  Even string matches as short as two octets
>   are effectively compressed.

<snip>

>   The efficiency of the LZS algorithm depends on the degree of
>   redundancy in the original data.  A typical compression ratio is 2:1.

What do you define to be "typical"?  Your Appendix A shows that the Calgary
files are compressed at a ratio of 2.04:1 for 4096 bytes datagrams, a very
non common MTU.

<snip>

>2. Compression Process
>
>2.2 Anti-expansion of Payload Data
>
>   The maximum expansion produced by the LZS algorithm is 12.5%.
>
>   If the size of a compressed IP datagram, including whatever overhead
                                                       ^^^^^^^^^^^^^^^^^
?

<snip>

>2.4 Compression Encoding Format
>
>   The input to the payload compression algorithm is an IP datagram
>   payload. The output of the algorithm is a new (and hopefully smaller)
>   payload. The output payload contains the input payload's data in
>   either compressed or uncompressed format. The input and output
>   payloads are each an integral number of bytes in length.
>
>   If the uncompressed form is used, the output payload is identical to
>   the input payload and the IPComp header is omitted.  

IPComp header is added _only_ to compressed payloads.

<snip>

>2.5 Padding
>
>   A datagram payload compressed using LZS always ends with the last
>   compressed data byte (also known as the <end marker>), which is used
>   to disambiguate padding.  This allows trailing bits as well as bytes
>   to be considered padding.

Could you specify compliance with the requirement:
  "The size of a compressed payload MUST be in whole octet units."

<snip>

>4. Security Considerations
>
>   IP payload compression potentially reduces the security of the
>   Internet, similar to the effects of IP encapsulation [RFC-2003].  For
>   example, IPComp makes it difficult for border routers to filter
>   datagrams based on header fields.  In particular, the original value
>   of the Protocol field in the IP header is not located in its normal
>   positions within the datagram, and any transport-layer header fields
>   within the datagram, such as port numbers, are neither located in
>   their normal positions within the datagram nor presented in their
>   original values after compression.  A filtering border router can
>   filter the datagram only if it shares the IPComp Association used for
>   the compression.  To allow this sort of compression in environments in
>   which all packets need to be filtered (or at least accounted for), a
>   mechanism must be in place for the receiving node to securely
>   communicate the IPComp Association to the border router.  This might,
>   more rarely, also apply to the IPComp Association used for outgoing
>   datagrams.
>
>   When IPComp is used in the context of IPSec, it is not believed to
>   have an effect on the underlying security functionality provide by
>   the IPSec protocol; i.e., the use of compression is not known to
>   degrade or alter the nature of the underlying security architecture
>   or the encryption technologies used to implement it.

Do you see the duplication of the "Security Considerations" from
<draft-ietf-ippcp-protocol-01.txt> necessary?
 
>5. References

Are you sure all the references are required?

=== end of comments ===