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

Re: commit bit processing



Dan,

As you mentioned - both implementations have to violate existing darft-standards,
which I am sure will change to accomodate this oversight.

>From the ease of the implementation standpoint - I suggest to do it as a part of
the QM exchange - it is also more logical to "connect" CONNECTED message to the QM
exchange just concluded.

Also, the current logic of  IV calculation for Informational Exchanges - is simply
to calculate a brand new IV for each Informational Exchange  - because they have
unique message IDs. I think it is easier to leave this rule and  logic as is.
Otherwise some Informational Exchanges have to be decrypted with running QM IVs
and some with the newly calculated IVs.

And by the way - this is our implementation :), even though at the moment we do
not rely on receiving CONNECTED message.

Slava
IRE


Daniel Harkins wrote:

>   More inconsistencies....sigh.
>
>   The base ISAKMP draft contains some contradictory language concerning the
> use of the commit bit. In discussions with other vendors about how they
> interpreted the contradictions the following theme came out: if the commit
> bit is set in a phase 1 exchange send back INVALID_FLAGS and regardless of
> who set the bit (initiator or responder) the responder sends the CONNECTED
> message back as the final message. Yes, that's not 100% compliant with what
> the draft (RFC?) says but it is impossible to be 100% compliant. And since
> it doesn't make any sense to send a COMMIT in a phase 1 exchange it doesn't
> make any sense to support that.
>
>   But! Another conflict has arisen. Two vendors interpreted the aforementioned
> contradictory text the same way but still do not interoperate. One vendor
> read the ISAKMP text where it says that the CONNECTED message is sent in an
> Informational Exchange with the message ID of the phase 2 (Quick Mode
> Exchange) to which it applies and then read IKE where it says all
> Informational Exchanges must have a unique message ID. Weighing these two
> issues and since the state that's waiting around for this message is part of
> the Quick Mode, this vendor implemented his IKE to expect the CONNECTED
> notify in a message whose exchange is Quick Mode. Another vendor read the
> same text and tried to be as faithful as possible to the ISAKMP draft and
> sends the CONNECTED notify in an Informational Exchange with the message ID
> of the Quick Mode, and has plumbing to clean up the right Quick Mode state
> with the Informational message.
>
>   Can those of you who've implemented the COMMIT bit in your code announce
> how you've done it. The text in one or both of those drafts (RFCs?) has got
> to change and it really doesn't matter how, whether the first vendor or the
> second vendor ends up changing his code isn't important. It would just be
> nice to get a feeling on how the WG wants to go and how the drafts (RFCs?)
> will eventually get rewritten to be consistent so that one of these guys
> can change his code. So, which way is right? Informational or Quick Mode?
>
>   Dan.






Follow-Ups: References: