Date: Sun, 1 Oct 2000 18:28:30 -0700 (PDT) From: Avram Shacham To: ippcp@external.cisco.com, royp@cisco.com cc: ipsec@lists.tislabs.com Subject: VPN Workshop - IPComp group meeting minutes The town-hall meeting on IPComp took place in the VPN workshop in San Diego on September 20, 2000. The minutes of that meeting are detailed below. Of the issues discussed, only issue #4 -- and less likely #3 -- should be reflected in rfc2393bis. I plan to issue the next version of the rfc2393bis I-D soon, following the discussion on those issues on the lists. Your prompt comments and suggestions are solicited. Regards, avram (1) IPComp Interoperability Report With about 30 IPv4 and two IPv6 IPComp implementations present in the bakeoff, the time seems ripe for preparing the IPComp Interoperability Report, which should be submitted to the IESG as part of the move to Draft Standard. Several IPComp implementations, who successfully interoperated, already expressed interest in being included in the report, but, for sure, the more the better. Please email me if you are interested in joining the report, thanks. (2) CPI size in IPComp proposal (2/4 bytes) Several implementations are yet to incorporate the consensus reached in the January 2000 VPN workshop for the CPI (SPI) field size. A typical interoperability problem occurred when an implementation that supports only a proposal with 32-bit CPI field rejected a proposal with CPI defined in a 16-bit (2 octet) field. In conversation with those implementors, I understood that they plan to modify their code ASAP. The consensus, as defined in draft-shacham-ippcp-rfc2393bis-05.txt, was reiterated: 4.1. Use of IKE [...] The CPI is sent in the SPI field of the proposal, with the SPI size field set to match. The CPI SHOULD be sent as a 16-bit number, with the SPI size field set to 2. Alternatively, the CPI MAY be sent as a 32-bit value, with the SPI size field set to 4. In this case, the 16-bit CPI number MUST be placed in the two least significant octets of the SPI field, while the two most significant octets MUST be set to zero, and MUST be ignored by the receiving node. The receiving node MUST be able to process both forms of the CPI proposal. (3) Stand-alone IPComp negotiated via IKE The rfc2393bis I-D includes the following clarification, reflecting the discussions on the ippcp list: 4.1. Use of IKE [...] Using IKE, IPComp can be negotiated as stand-alone or in conjunction with other IPsec protocols. Several implementors objected to that clause on the ground that IPComp is not a security protocol. In a straw-poll, several implementors (more than 10, according to my count) pointed out that they already implemented negotiation of stand-alone IPComp via IKE. On the way to Draft Standard, where unused features of a protocol should be removed, that many implementations dictate -- imo -- that the above clause should stay. What is the opinion on the lists? (4) Use of well-known CPI in IKE negotiation IPCAs become non-unique in the following scenario: (a) Two or more IPComp session are established between two nodes. (b) A well-known CPI is used. Non-unique IPCAs pose problems in reaching attributes specific to each IPCA, either negotiated (e.g., lifetime) or internal (e.g., the counters of the adaptive algorithm for handling previously compressed payload). To be sure, when only a single session is established between two nodes, the IPCA is unique even when using a well-known CPI. In addition, the above scenario can be avoided by using the negotiated CPIs (256-61439). Several implementations, who chose to utilize the well-known CPIs in such scenarios, used extra information to identify the IPCA, such as the Protocol Suite (or bundle or enclosing) SA that includes that IPCA. In the town-hall discussion and a thread that followed on ipsec list, several suggestion were raised for the above scenario: (a) OK to negotiate with well-known CPI, but only when no other attributes are negotiated. (b) Identify the IPCA as part of the Protection Suite (bundle). (c) Use only negotiated CPIs when more than one session is established between two nodes. There was no conclusion to the town-hall discussion on that issue and the matter is now before the lists. I'd suggest to add an implementation note to rfc2393bis that identifies that problem and recommends (c). (5) DEFLATE (RFC 2394) The discussion on using DEFLATE header and Adler32 checksum, which started in the town-hall meeting in the VPN workshop in January 2000, continued. In a straw-poll, _all_ implementors indicated support for NOT including the extra information. Roy, could you please issue rfc2394bis that reflects that consensus? === eom ===