[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPComp rfc2393bis-00
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.
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.
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. 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: