[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: Summary of responses: Network World article on IPSec
> >The fact that the IKE header is unprotected has been recognized by its
> >designers since day one. If you're worried about active attacks on an
> IKE
> >exchange, all you really need to do is eat the last packet of any QM or
> MM.
> >Why worry about changing a bit? But, if you've got active attacks going
> on,
> >the same attacker could just as easily eat the resulting AH/ESP
> traffic...
> >Frankly, I'm not worried about this right now.
>
> Active attacks aside, unlike a lost last packet in an IKE exchange, the
> setting of the commit bit by a glitch in the wire, however improbable,
> will break the negotiation. In the lost packet case, the retransmission
> timer should generally enable the negotiation to recover. Retransmitting
> in the commit bit glitch case does not recover since one side is expecting
> an IE connect message and the other side doesn't believe it needs to send
> it.
>
> Until the flags and version fields of the ISAKMP header are authenticated
> (that you Tero Kivinen for catching this) commit bit implemenations need
> to keep
> this problem in mind. One way to recover is described in the note under
> the
> commit bit description in ISAKMP. This method only works if the side that
> didn't see the glitch needs to send an IPSec packet. For the case where
> only one side currently needs to send an IPSec packet and it is the side
> that received the glitch, it needs to have a retransmission timer while
> waiting
> for the IE connected message. The IE connected message will never come
> but
> at least the retry counter will eventually reach the retry limit and a new
> QM
> exchange can be initiated.
>
> By the way, what was the general consensus for the connected message?
> ISAKMP states that it MUST go in an IE that has the same message id as
> the QM it pertains to and IKE states that the message id MUST NOT be
> the same as the QM it pertains to (or any other phase 2 exchange). There
> was also some talk of not using IE but extending QM instead. If IE with
> the same message id is used, is the IE IV generated via the normal IE IV
> method (that is it would be the same as the initial IV that was used for
> the
> associate QM) or does it use the last ciphertext block of the QM instead
> (seeing as it's using the same message id)?
>
> -dmason
>
>
>
>