[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Results of the IPSEC document reading party
At 11:25 AM 12/23/97 -0800, Daniel Harkins <dharkins@cisco.com> wrote:
> Alexei,
[ "Alexei V. Vopilov" <alx@elnet.msk.ru> wrote ]
>> -------------------
>> This observation of ISAKMP-OAKLEY-05
>>
[ ... ]
>> : 2. should mention that phase 1 SA offers consist of a single proposal
>> : with possibly multiple transforms and not multiple proposals-- the
>> : protocol has to be ISAKMP anyway so multiple proposals doesn't really
>> : make sense.
>>
>> Sorry, but the proposal payload itself does not really make sense for
>> an _ISAKMP SA_ , as well as the 'SA' term does not really correspond to
>> an _ISAKMP SA_. It's just reuse of ISAKMP syntax and probably in the
>> not best way.
>
>How do you negotiate ISAKMP SA parameters then? Of course the proposal
payload
>makes sense for an ISAKMP SA. The issue is does one have a single proposal
>with possibly multiple transform payloads or does can one have multiple
>proposal payloads each with a single transform payload? It was never spelt
>out whether the latter is "legal". The consensus was that it is not.
[ ... ]
> c praznikom,
>
> Dan.
Is this in fact consensus? I.e. that you're not allowed to use two
Proposals in an ISAKMP-SA offer, but must use one with multiple Transforms.
It is, as Dan says, not spelled out and it's strictly arbitrary. Did an
ISAKMP author (Doug) announce his intention to include such a limitation in
the next version of the draft?
Our implementation accepts offers structured either way; in offers which we
send, the structure can be explicitly configured either way. As things
were last September (last bakeoff), doing otherwise seemed brain-dead to
me; implementors shouldn't be forbidding variations allowed by the draft.
I don't see why the draft should introduce limits like this at this late
date, in absence of strong arguments.
Best regards
- John Burke
Follow-Ups: