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

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 ===