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

Re: IPComp rfc2393bis-00



Mike,

At 05:13 PM 11/22/99 -0500, Mike Williams wrote:
>I have a couple of questions with regards to negotiating IPCOMP with
>ISAKMP.
>
>IPComp draft rfc2393bis-00.txt explains that the CPI should be sent in
>the SPI field of the proposal payload when using ISAKMP to negotiated
>IPComp.  This draft goes on to explain that 16 bit CPIs should be used,
>however 32 bit CPIs (SPIs) should be tolerated. Using the CPI, rather
>than a unique SPI for each associations leads to a couple of problems.

Why can't CPI be unique (as in the range 256-61439)?

>First, it is not possible to send a single proposal which contains
>multiple IPComp transforms with different transform IDs.  For example,
>the only way to negotiate IPComp with DEFLATE or LZS would be with 2
>proposals since the SPI is part of the proposal payload.

<draft-shacham-ippcp-rfc2393bis-01.txt> specifies in section 4.1
(in identical words as rfc2393) -

   An IPComp Association is negotiated by the initiator using a Proposal
   Payload, which includes one or more Transform Payloads.  The Proposal
   Payload specifies the IP Payload Compression Protocol in the protocol
   ID field and each Transform Payload contains the specific compression
   algorithm(s) being offered to the responder.

Indeed, when the CPI is in the well-known range, i.e., the CPI
is identical to the algorithm-ID, a proposal can include only a single 
algorithm -- as was discussed several times on these lists. 
In order to offer two or more algorithms in the same proposal, 
the CPI in the range 256-61439 is adequate.

>Additionally, and more importantly is that there is no way to uniquely
>identify an IPComp Association.  It is entirely possible that 2 systems
>may have more than 1 IPComp Association (maybe part of an SA bundle with
>IPSec) using the same compression algo.  

Again, when the CPI is negotiated in the range 256-61439, what blocks
implementations from identifying IPComp Associations?

avram

>In this case, there is no way
>to send a ISAKMP DELETE (which uses the SPI) to stop using one, but not
>the other.
>
>My questions are:
>
>1) Why does this draft specify that the CPI MUST be sent as the SPI?  I
>am assuming that there is some history here that I am not aware of?  It
>seems redundant since the negotiated transform contains the compression
>algo which is also the CPI.
>
>2) How are ISAKMP DELETEs handled for IPComp Associations?  Are there
>implementations that are sending them?
>
>Any information that can be provided would be greatly appreciated.
>
>Thanks,
>Mike Williams
> 



Follow-Ups: References: