RE: IPCOMP and Tunnel Mode
Tim Jenkins <tjenkins@TimeStep.com> Thu, 20 August 1998 21:50 UTC
Return-Path: tjenkins@TimeStep.com
Received: from beasley.cisco.com (autorespond.cisco.com [171.69.2.135]) by ftp-eng.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA19415 for <ippcp-archive-file@ftp-eng.cisco.com>; Thu, 20 Aug 1998 14:50:35 -0700 (PDT)
Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by beasley.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id FAA03185 for <ippcp-archive-file@ftp-eng.cisco.com>; Thu, 20 Aug 1998 05:11:25 -0700 (PDT)
Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id FAA22819 for <extdom.ippcp@aliashost.cisco.com>; Thu, 20 Aug 1998 05:12:34 -0700 (PDT)
Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id FAA18845 for <ippcp@external.cisco.com>; Thu, 20 Aug 1998 05:11:03 -0700 (PDT)
Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id FAA10992 for <ippcp@external.cisco.com>; Thu, 20 Aug 1998 05:11:24 -0700 (PDT)
Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id FAA19712 for <ippcp@external.cisco.com>; Thu, 20 Aug 1998 05:11:01 -0700 (PDT)
Received: from ns.newbridge.com(192.75.23.67) by proxy3.cisco.com via smap (V2.0) id xma019701; Thu, 20 Aug 98 12:10:57 GMT
X-SMAP-Received-From: outside
Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id IAA09381; Thu, 20 Aug 1998 08:07:13 -0400 (EDT)
Received: from kanata-gw1.newbridge.com(192.75.23.72), claiming to be "kanata-gw1.ca.newbridge.com" via SMTP by ns.newbridge.com, id smtpdAAAa09379; Thu Aug 20 08:07:10 1998
Received: from kanmaster.newbridge.com by kanata-gw1.ca.newbridge.com via smtpd (for ns.newbridge.com [192.75.23.67]) with SMTP; 20 Aug 1998 12:07:09 UT
Received: from exchange.timestep.com (exchange.timestep.com [192.168.219.193]) by ca.newbridge.com. (8.8.8/8.8.6) with ESMTP id IAA08507; Thu, 20 Aug 1998 08:07:08 -0400 (EDT)
Received: by exchange.timestep.com with Internet Mail Service (5.5.2232.9) id <Q0L67QCG>; Thu, 20 Aug 1998 08:08:35 -0400
Message-ID: <319A1C5F94C8D11192DE00805FBBADDF32A41B@exchange.timestep.com>
From: Tim Jenkins <tjenkins@TimeStep.com>
To: Avram Shacham <shacham@cisco.com>
Cc: ipsec@tis.com, ippcp@external.cisco.com
Subject: RE: IPCOMP and Tunnel Mode
Date: Thu, 20 Aug 1998 08:08:35 -0400
Return-Receipt-To: Tim Jenkins <tjenkins@TimeStep.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BDCC33.41AA0CC0"
The attempt to avoid possible fragmentation is a good one (your wording "will" is too strong), however: 1) No compression occurs for small packet sizes (below the threshold of the particular algorithm) 2) We're talking IPSec tunnel mode, which has to add another IP header, so the packet's going to grow anyway 3) The IPComp header is 4 bytes. Thus, the net increase is 24 bytes. If we assume that the smallest MTU in the network is 576 bytes, that means that packets that don't get compressed that are 552 bytes to 556 bytes in size will cause fragmentation under these conditions. What is the probability that there will be no compression of packets of that size? Does someone have any statistics on the probability of larger packets expanding during compression, thus not being compressed, so that this can be used as part of this discussion? On the issue of the flags: The bits are there. If they can be made to provide some useful purpose, they should. I note that this document (draft-ietf-ippcp-protocol-06.txt) was *not* one of those advanced to Proposed Standard. The document also states that the flag bits are reserved for future use. Perhaps this could be a future use. This discussion is based on the trade-offs between performance at the network level (possible fragmentation) and performance at the computational level (inconsistent implementation). Given equal probability of impacting both, I would design in favour of the network. However, in this case, I don't know that the probabilities favour the network. --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com <http://www.timestep.com/> (613) 599-3610 x4304 Fax: (613) 599-3617 -----Original Message----- From: Avram Shacham [mailto:shacham@cisco.com] Sent: Wednesday, August 19, 1998 10:32 PM To: Tim Jenkins Cc: ipsec@tis.com; ippcp@external.cisco.com Subject: Re: IPCOMP and Tunnel Mode Tim, At 04:03 PM 8/19/98 -0400, Tim Jenkins wrote: >>>> 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. 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. 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... Comments encouraged (although I doubt most of you need that...) :-) 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
- RE: IPCOMP and Tunnel Mode Tim Jenkins
- RE: IPCOMP and Tunnel Mode Bob Monsour
- Re: IPCOMP and Tunnel Mode Avram Shacham
- RE: IPCOMP and Tunnel Mode Paul Koning