ISAKMP Questions

WaterhouseR <WaterhouseR@mail.ndhm.gtegsc.com> Thu, 31 October 1996 22:36 UTC

Received: from cnri by ietf.org id aa28004; 31 Oct 96 17:36 EST
Received: from neptune.hq.tis.com by CNRI.Reston.VA.US id aa23517; 31 Oct 96 17:36 EST
Received: by neptune.TIS.COM id aa26383; 31 Oct 96 16:31 EST
Received: from neptune.tis.com by neptune.TIS.COM id aa16788; 31 Oct 96 10:55 EST
Message-ID: <n1365366045.9976@mail.ndhm.gtegsc.com>
Date: Thu, 31 Oct 1996 10:02:17 -0400
From: WaterhouseR <WaterhouseR@mail.ndhm.gtegsc.com>
Subject: ISAKMP Questions
To: IPSEC Working Group <ipsec@tis.com>
X-Mailer: Mail*Link SMTP-MS 3.0.2
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

The following is based on draft-ietf-ipsec-isakmp-05.

I find myself confused re the following.

3.5.6 says "If the basic exchange types are inadequate to meet the
requirements within a DOI, a designer can define up to thirteen extra exchange
types per DOI."

Now Exchange Type is carried in the Header, but DOI is carried in the SA
Payload. This seems to imply that every Exchange Type must begin with an SA
Payload, something which is probably harmless in Phase 1. But in Phase 2, it
appears to have the further implication that the SA Payload be unencrypted
(since you can't process the Header without accessing the SA Payload). It has
the further implication that if the Payloads are encrypted only one SA can be
negotiated at a time between a pair of Negotiation Servers (since you need
access to the SPIs to interpret Exchange Type if you are trying to negotiate
for more than one association at the same time).

My initial reaction is that DOI is mispositioned to support the more general
capability suggested in 3.5.6. But perhaps I am overlooking something.