Re: IPsec and Oakley test items

[Daniel Harkins <[e-mail]>]

  Greg,

  There's already a discrepancy between ISAKMP/Oakley and the base ISAKMP
spec on this subject: note there's no hash in the exchange in section 4.8
in the base ISAKMP draft (also unchanged from previous versions). It has to 
be so because the base ISAKMP spec doesn't spell out a specific key exchange 
and doesn't deal with SKEYID_foo or message encryption and authentication.

  But my intent is not to add gratuitous changes to increase the discrepancies
between the drafts. I really have a reason. 

  Informational exchanges are unidirectional and one does not set a 
retransmition timer when sending them. If you use the M-ID of the phase 2 
exchange which (for whatever reason) caused the notify message in the first 
place to "identify" the corresponding state you're maintaining then you also 
have to use the IV from that same phase 2 exchange. Now, if that notify gets 
lost in the ether your IVs are out-of-sync and the next message will decrypt 
wrong, which will probably cause you to generate another notify, which will 
be encrypted with an out-of-sync IV and cause a decryption failure by the 
other party who will respond with a notify which you will be unable to 
decrypt.... until you both throw up your hands and give up.

  On the other hand, if the exchanges are decoupled (they've got different
exchange identifiers too, so the informational exchange really is different
than a Quick Mode exchange) packet loss will not result in complete chaos.
In fact, the other party who never received your notify would probably 
retransmit the original problematic offer and you'd send another notify
(which odds are, he'd get) which he could properly handle.

  I could also argue that this is not a discrepancy with the base ISAKMP
spec. The M-ID and SPI would still identify the correct state as dictated
by section 2.4. It's just that the M-ID and SPI would be in the body of
the notify message as the ISAKMP header and SA payload to which the notify
refers. The ISAKMP header of the Informational Exchange would be unique
to the Informational Exchange.

  Dan.

> Below are a few relevant sections from the latest ISAKMP (unchanged from
> previous versions).  I think it is clear that a Notification that is
> concerned with a Quick Mode should use the same M-ID as that of the
> Quick Mode.  And that it is acceptable to identify in progress Quick
> Modes by that M-ID (along with the cookies).  
> 
> Using SPI alone to match up in progress Quick Modes is cumbersome,
> especially for exchanges which involve multiple SPIs.  If I can key off
> the M-ID its much easier to single out the failed negotiation.
> 
> Regardless, there is discrepancy between ISAKMP and your proposed
> additions to ISAKMP/Oakley.  You can probably figure out which one I
> want.