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

Re: Comments on draft-ietf-ipsec-new-auth-00.txt



  Steve,

  In Memphis there was general agreement that AR must always be sent but that
the receiver could elect to check it or not (it is in the receiver's best
interest to do so anyway). You objected with the following point:

> 	- it is true that the AR window protects the receiver, and imposes
> no changes in how the sender operates.  However, I think that the use or
> non-use of use of AR is of interest to the sender.  If communication
> performance problems arise between two IPSEC sites, one reason might be the
> rejection of some number of packets due to the size of the AR and the
> out-of-order delivery characteristics associated with the path.  Certainly,
> if a default window size of 1 were adopted (as had been suggested), there
> would be a significant opportunity for such behavior.  However, if the use
> of AR is purely at the discretion of the receiver, I have no way of knowing
> if that might be a problem, if I am troubleshooting the problem from the
> sender's end.  So, at a minimum, I'd like to know if AR is a characteristic
> of each SA.

I don't see this as a compelling arguement. If you want to troubleshoot the
problem from the sender's end, you always assume it is being used. (If it is
not then AR is not the problem). I can't see such troubleshooting being done
in a vacuum anyway. For the sender to determine the cause of a large number 
of his packets being rejected by the receiver, some coordination with the 
receiver is necessary (like phoning the site and asking whether anything 
interesting is in the audit logs, or accessing some IPsec MIB on the
receiver).

This WG seems to have a tendancy to say "oh, just let key management handle
that" and AR (and the size of the AR window!) seems to fall into this
category. A problem with this is that the more things key management must
negotiate the more likely all offers from initiator will be rejected by the
responder. And (the voice of experience talking here) that is a difficult
problem to troubleshoot. 

Another point raised in Memphis is that complexity can introduce subtle bugs
in code. Since we're talking about security code, a subtle bug can be a
security hole. Is a relatively simple, secure 95% solution better than a
complex, potentially problematic 97% solution? I think so. There will always
be obscure edge conditions for which IPsec is a solution but not an optimal 
one. (Also, note that the more options to negotiate the more complex the method 
of configuration-- and the more complex the configuration itself-- and the more 
likely that a system can be misconfigured, with potentially tragic results).

AR being always sent, optionally used, and a window size of 32 is a relatively
simple solution that can be implemented straighforwardly without worrying
about special case coding. It may not be the best solution for every single
potential use of IPsec but for the vast majority it is.

  regards,

  Dan.



References: