Subject: IETF/Munich meeting report

From: Roy Pereira <[email-masked]>
Date: Mon, 18 Aug 1997 23:10:07 -0400

IETF/Munich August 13, 1:00pm
=============================

Naganand Dorswamy (chairman)
----------------------------

Purpose: 
	can't compress when you encrypt

Meeting Agenda: 
	charter, architecture, protocols

Charter:
	IPCOMP must work with or without IPSec.
	Doesn't deal with transport layer, just network layer
	Must support manual and key management protocol negotiation

Bob Monsour
-----------

Presented the Architecture and the Document Roadmap.
2 approaches in doing IP compression: ip-in-ip or a compression header.
ip-in-ip cannot handle session-to-sesstion associations.

Matt Thomas
-----------

Presented his new IPCOMP header protocol.  
Participants later slightly modified the protocol presented.
The new protocol was

  +-------------+-------------+-----------------------------+
  | Next Header |    Flags    | Compression Parameter Index |
  +-------------+-------------+-----------------------------+

Avram Shacham
-------------
URL of presentation: www.tgv.cisco.com/public/shacham/ipcomp.ppt
Avram presented his IP-in-IP compression protocol.
Why use IP compression?
When to use IP compression? Slow links, congested links, CPU speed.
Performance increase of 1.7 for 28.8k
Performance decrease of 0.7 for 10M

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

Closed Issues
-------------
1.  IPCOMP must be done before IPSec
2.  Should we use stateless or state compression (state compression is
only usefull at the TCP layer).  Stateless.
3.  Allow a sesion based CPI protocol (like Matt Thomas')
4.  Should we always compress even when compression expands the packet?
NO.
5.  Should we send a IPCOMP header even if we do not compress? NO.
6.  Should we use attributes or a new protocol in ISAKMP to negotiate
IPCOMP? Protocol.
7.  The IPCOMP protocol must allow per Upper Layer Protocol sessions.

---

From: [email-masked]
Date: Tue, 19 Aug 1997 08:23:23 -0500

______________________________ Reply Separator _________________________________
Subject: IETF/Munich meeting report
Author:  Roy Pereira <[email-masked]> at Internet
Date:    8/18/97 11:10 PM

     
Purpose: 
     
Meeting Agenda: 
     
Charter:
        
>> Aren't lines 1 and 3 in the charter contradictory?  If IPSec is absent, then 
there is no key management protocol (IPCOMP is not a security protocol).  Or 
does line 3 mean that even if IPSec is not present, ISAKMP must be implemented 
for IPCOMP to work?  If so, then I have a problem with it.  I don't want to have
to understand the various IPSec documents to have to implement IPCOMP.  Plus, 
mandating the use of ISAKMP to negotiate compression algorithms is too much of 
an overkill.  I thought that this was identified as an open issue for the 
working group at the meeting.

I feel that it is ok to use ISAKMP to achieve the short term goal of this 
working group (get IPCOMP to work with IPSec).  But if IPCOMP is ever to be a 
standalone protocol, we need a simple, lightweight method to negotiate 
algorithms.  I know that this means implementing yet another protocol, but the 
charter does state that IPCOMP must work without IPSec.  Someone at the meeting 
suggested using some kind of an out of band mechanism (non-standard way) to 
negotiate compression algorithms.  But this gurantees non-interoperability.

I think that this should be moved to the open issues list.

Thanks,

Sumit A. Vakil
Software Engineer
3Com Corporation

---

From: Roy Pereira <[email-masked]>
Date: Tue, 19 Aug 1997 12:45:10 -0400

>working group at the meeting.

Actually lines 1 and 3 mean virtually the same thing.  The charter is to
have an IP Compression protocol that will work whether IPSec is there or
not.  Thus we must support some method of setting up compression
associations without ISAKMP.  The reason that ISAKMP was chosen, was
because it is the KMP of IPSec and it was designed to work with other
protocols other than IPSec.  Building yet another negotiation protocol
would be too costly.

>I think that this should be moved to the open issues list.

I believe that this issue will be a major one, thus I would hope that we
stabilize IPCOMP with IPSec and then we can get bogged down with what to
do when IPSec is not there.

---

From: [email-masked]
Date: Tue, 19 Aug 1997 16:12:19 -0500

>I think that this should be moved to the open issues list.
     
-I believe that this issue will be a major one, thus I would hope that we 
-stabilize IPCOMP with IPSec and then we can get bogged down with what to 
-do when IPSec is not there.

I agree absolutely.  Plus, do we know if there really is a demand for 
IPCOMP in the absence of IPSec?

---

From: Bob Monsour <[email-masked]>
Date: Tue, 19 Aug 1997 23:59:24 -0700

At 04:12 PM 8/19/97 -0500, [email-masked] wrote:
[snip...]
>IPCOMP in the absence of IPSec?

I suggest that when we can agree on the basic protocol and how to use
ISAKMP to do the negotiation for IPCOMP in IPSec environments, we need to
address the exact question that you raise. It's not clear to me how much
interest there is in IPCOMP without IPSec for the primary reason that
without IPSec, it could be more effective to compress at a higher layer
where you have the chance to reduce the number of IP packets, or
alternatively, simply let the link layer compression (in PPP environments)
kick in and get the advantages of stateful compression.

It will be interesting to see if there is critical mass support in solving
the IPCOMP in non-IPSec contexts.

-Bob

---

From: Naganand Doraswamy <[email-masked]>
Date: Thu, 28 Aug 1997 09:49:00 -0400

>IPCOMP in the absence of IPSec?
The way we are defining the base protocol, I dont see it being tied to
IPsec or any key mgmt protocol. The base protocol header has only three
fields. CPI is the contract between the two entities and we are saying that
it can be either negotiated offline or online using any key mgmt protocol.
Since ISAKMP is the standard key mgmt protocol, we are recomending its use.
However, as in the case of IPsec we could use any key mgmt protocol.

At this point, I dont see this being used in the absence of IPsec.

--Naganand

-----------------------------------------------------------------
Naganand Doraswamy				(508)916-1323 (O)
Bay Architecture Lab				(508)670-8153 (Fax)
3 Federal St, Mail Stop BL3-04
Billerica, MA 01821

---

From: [email-masked]
Date: Thu, 28 Aug 1997 12:12:23 -0500

So, if I understand you correctly, IPCOMP recommends using ISAKMP as a 
     means to dynamically negotiate compression parameters.  But IPCOMP is 
     supposed to work in the absence of IPSec also.  Therfore, if IPSec is 
     not implemented, and dynamic compression parameters negotiation is 
     desired, an implementation should either implement ISAKMP or some 
     non-standard negotiation protocol, and hope that the peer implements 
     the same?  And since the working group recommends ISAKMP, an 
     implementation can increase its chances of interoperating with a peer 
     if it implements ISAKMP (again in the absence of IPSec)?
     
     I feel that it is ok for the working group to recommend the use of 
     ISAKMP to achieve its short-term goal (get IPCOMP to work with IPSec). 
     But ISAKMP should not be recommended as a negotiation protocol for 
     IPCOMP in the absence of IPSec.

     Sumit A. Vakil
     3Com

______________________________ Reply Separator _________________________________
Subject: Re: Re[2]: IETF/Munich meeting report
Author:  Naganand Doraswamy <[email-masked]> at Internet
Date:    8/28/97 9:49 AM

     
--Naganand