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

Re: IPCOMP and Tunnel Mode

Tim,


At 04:03 PM 8/19/98 -0400, Tim Jenkins wrote: 

>>>>

<excerpt>

<fontfamily><param>Arial</param><smaller>I have some concerns about one
of the requirements of the IPCOMP draft. It states that if no compression
is actually done, no IPCOMP header should be added. While this may be
fine in transport mode, it leads to the appearance of an IP-in-IP packet
in tunnel mode.

</smaller></fontfamily>

<fontfamily><param>Arial</param><smaller>This concerns me, since it seems
that the only way to be sure that the inbound IPCOMP SA should handle
packet is to perform an SA lookup to see if it should have been
compressed. (Issues of policy verification on inbound packets are
intentionally left out of this discussion.) This leads to inconsistent
processing of inbound SAs.

</smaller></fontfamily>

<fontfamily><param>Arial</param><smaller>As an alternative, I implemented
using one of the flag bits to indicate that there was no compression and
left the IPCOMP header in. This allowed a consistent lookup on inbound
processing for an SA based on SPI (or the IPCOMP equivalent). I have also
implemented the policy lookup method, and the full-time use of the IPCOMP
header was much cleaner...

</smaller></fontfamily>

<fontfamily><param>Arial</param><smaller>Comments encouraged (although I
doubt most of you need that...) :-)</smaller></fontfamily> 

</excerpt>

The draft (rfc?) (sorry Dan, I could not avoid following your style :),
while defining the non-expansion policy, explains the reason for not
adding the IPCOMP header in that scenario (see the marked lines):


2.2. Non-Expansion Policy


   If the total size of a compressed ULP payload and the IPComp header,

   as defined in section 3, is not smaller than the size of the 
original

   ULP payload, the IP datagram MUST be sent in the original

   non-compressed form.  To clarify:  If an IP datagram is sent

   non-compressed, no IPComp header is added to the datagram.  This

|  policy ensures saving the decompression processing cycles and

|  avoiding incurring IP datagram fragmentation when the expanded

|  datagram is larger than MTU.


In other words, when the size of a non-compressible packet is MTU, your
suggestion to add the IPCOMP header will cause packet fragmentation.


The wg debated having always an IPCOMP header, even when the packet in
sent without compression. As such policy is actually equivalent to
lowering the MTU by four octets, the wg decided to reject this 
proposal.


In addition, your implementation does not comply with the requirement to
set the flags field to zero:


3.3.  IPComp Header Structure


   [snip]


   Flags


        8-bit field.  Reserved for future use.  MUST be set to zero.

        MUST be ignored by the receiving node.


As for the implementation issues that you raised, there were several
interoperable stacks with IPComp in the bake-off last March, so working
draft-compliant solutions do exist.


Regards,

avram
References: