Re: changes in draft-ietf-ippcp-lzs-03.txt

[Avram Shacham <[e-mail]>]

Robert,

As an implementor of LZS in IPComp, I can easily state that the document
provides all the information required to incorporate LZS in the context of
IPComp.

The main suggestion that I would like to re-raise: Could you minimize the
duplications from the IP Payload Compression Protocol document?  The
benefits of such separation are obvious. I pointed to few examples in the text.

Also, see some editorial comments attached.

Regards,
avram

>                    IP Payload Compression Using LZS
>                      <draft-ietf-ippcp-lzs-03.txt>

<snip>

>2.2 Anti-expansion of Payload Data

<snip>

>   If the size of a compressed IP datagram, including the Next Header,
>   Flags, and CPI fields, is not smaller than the size of the original
>   IP datagram, the IP datagram MUST be sent in the original non-
>   compressed form, as described in [IPCOMP].

Duplication...

>2.3 Format of Compressed Datagram Payload

<snip>

>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |  Next Header  |     Flags     | Compression Parameter Index   |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Duplication...

<snip>

>4.1 ISAKMP Transform ID
>   The LZS Transform ID as 0x03, as specified in The Internet IP
>   Security Domain of Interpretation [SECDOI].  This value is used to
>   negotiate the LZS compression algorithm under the ISAKMP protocol.

The [IPDOI] defines:  

      Trabsform ID     Value
      ------------     -----

      IPCOMP_LZS       3

Could you reference the Transform ID name, in order to avoid a possible
confusion if and when the value changes?

<snip>

>4.3 Manual configuration
>   The CPI value 0x03 is used for a manually configured IPComp
>   Security Associations.
    ^^^^^^^^  
    Compression ?

Also, see comment to 4.1.

<snip>

>5. 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.

Is this not-updated duplication really needed?  I recommend following Roy's
DEFLATE document that simply states:

>   This document does not add any further security considerations that
>   [IPCOMP] and [Deutsch96] have already declared.

=== end of comments ===