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

Quick Mode For Multiple SAs



I'm puzzled over the various descriptions throughout the IPSEC documents
with regards to negotiating multiple SAs simultaneously.

The IKE document says (5.5):

       Using Quick Mode, multiple SA's and keys can be negotiated
       with one exchange as follows:
       [exchange with each packet containing multiple SA payloads]

Yet a page or two before that it says:

        The message ID in the ISAKMP header identifies a Quick Mode
        in progress for a particular ISAKMP SA which itself is
        identified by the cookies in the ISAKMP header. 

And:

        it is possible to have multiple simultaneous Quick Modes,
        based off a single ISAKMP SA, in progress at any one time.

Yet, in a seemingly contradictory statement, the ISAKMP document says (4.2):

        If the SA establishment negotiation is for a combined
        protection suite consisting of multiple protocols, then
        there MUST be multiple Proposal payloads each with the
        same Proposal number. These proposals MUST be considered
        as a unit and MUST NOT be separated by a proposal with a
        different proposal number. 

So, based on the above, there are now three somewhat contradictory ways of
negotiating multiple SAs at roughly the same time:

1] Perform multiple Quick Mode exchanges
2] Transmit multiple SA payloads in each packet [violating the ISAKMP
requirement]
3] Use multiple proposals with the same proposal number in one SA payload
(IMHO, the logical choice...)

And so, I suppose it really comes down to what the implementations are
actually doing.  If someone wants to negotiate ESP with IPCOMP, do we use
1, 2, or 3?  Using number 1 seems fairly non-functional since it results in
timing confusion as to which protocol is layered on top of the other in
addition to simply being much slower to negotiate.  Number 2 violates
ISAKMP and makes packet parsing more difficult.  Number 3 is logical, but
since the IKE document seems to recommend number 2, it remains unclear what
to do.

-Will






Follow-Ups: