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.
- ISAKMP Questions WaterhouseR