IPPCP - IETF/Munich August 13, 1:00pm Chair: Naganand Dorswamy Scribed by: Roy Pereira The IPPCP working group met for the first time in Munich. There were approximatly 35 attendees. The agenda in the meeting was to discuss the charter and resolve some architecture and protocol issues. The discussions on the charter did not change the charter that was approved by the IESG. The primary goal of the working group is to define a compression protocol. The primary goal is to make it work in the context of IPsec. However, the working group will define the protocol so that it is generic enough to work even when IPsec is not being used. As discussed in the charter, we will support both manual and dynamic negotiation of compression parameters such as algorithm. This working group does not deal with issues of compression at the transport layer. There were three presentations. Bob Monsour ----------- Bob presented the combined architecture draft: draft-ietf-ippcp-arch-00.txt which raised the following issues 1. Should we support per session based compression? 2. Should we support stateful or stateless compression? 3. Should we mandate whether compression should be used if it increases the size of payload and whether we should include the compression header in that case. 4. If used with a key mgmt protocol such as ISAKMP, should we negotiate compression as an attribute or as a protocol? There were two proposals for performing comrpession and this presentation highlighted the advantages and disadvantages of the two approaches- ip-in-ip or a separate protocol header. These issues have been discussed in the architecture draft as well. Matt Thomas ----------- Matt Thomas presented his draft although the protocol header that he presented was different than what was specified in his draft. The protocol header was then changed during the course of the meeting. The final protocol header that will be proposed to the working group is shown below. +-------------+-------------+-----------------------------+ | Next Header | Flags | Compression Parameter Index | +-------------+-------------+-----------------------------+ Avram Shacham ------------- Avram presented his draft draft-ietf-ippcp-ipcomp-00.txt. He discussed when and why it makes sense to compress packets before performing compression. It was mentioned during presentation it makes more sense to compress over slow links. Performance increase of 1.7 for 28.8k Performance decrease of 0.7 for 10M There were questions asked about whether it makes sense to compress packets even on fast links if the encryption algorithm is slow. There is no data to make any statments on this as most of the tests were performed using LZS compresson and DES and MD5 and encryption and hash. URL of presentation: www.tgv.cisco.com/public/shacham/ipcomp.ppt Resolutions ------------ The following were some of the things the working group agreed on. 1. IPCOMP must be done before IPSec 2. The compression should be stateless 3. The compression, if desired, should be on the granularity of a session. 4. If the compression expands the packet, then compression SHOULD not be performed and in that case the compression header SHOULD not be sent in the packet. 5. Compression should be implemented as a separate protocol. Open Issues ------ 1. Architecture document must state that all algorithm documents must state thresholds for whether compression should be performed. 2. We need to finalize the IPCOMP protocol (ie. bits of the wire). 3. Location of IPCOMP within IPv6 must be defined in architecture document. 4. Should a CPI failure send ICMP error messages? 5. Should we have static SA that are defined by predefined public CPI values? 6. Should IPCOMP be a "MUST used" before AH/ESP/frag/hop-by-hop 7. Should we mandate any one particular algorithm as mandatory to implement? Next Steps ----------- If possible, compress the protocol document and the architecture document into one and publish this document as soon as possible. This will enable us to decide on the header format so that people can implement this protocol. The open issues needs to be addressed in this document. It was a common consensus that this working group should be done with its commitments by the Washington IETF. --Naganand ----------------------------------------------------------------- Naganand Doraswamy (508)916-1323 (O) Bay Architecture Lab (508)670-8153 (Fax) 3 Federal St, Mail Stop BL3-04 Billerica, MA 01821