Re: [Ipsec-tools-devel] PATCH: remote-access client to Cisco ASA (3/3)
Brought to you by:
mit_warlord,
netbsd
From: Matthew G. <mg...@sh...> - 2007-09-14 20:55:15
|
Emmanuel Dreyfus wrote: > Matthew Grooms <mg...@sh...> wrote: > >> Right, I see what your talking about and that certainly was a bad >> suggestion. I had it in my head that these were stored as a bit map but >> obviously thats not the case. However, it does beg the question; Why >> does racoon track state for phase1, phase2 and even xauth but not for >> config? If we handled this uniformly, I don't think there would be the >> need for script state. Starting here would be the right thing to do in >> my opinion. >> >> With all that said, I think storing a script state in the phase1 handle >> is acceptable for the near term. > > IMO, we would be better reworking the script code, so that scripts gets > executed at reliable time. > > For now, we have phase1_up that can be executed after phase1 or after > xauth. We can retain phase1_up for backward compatiblity, note it is > deprecated in the documentation, and add > isakmp_up executed after phase 1 > xauth_up executed after xauth > modecfg_up executed after mode cfg > ipsec_up executed after phase 2 > > And all the counterpart *_down scripts Not sure if splitting the scripts is a good idea or not, but this would just push the problem from phase1_up down into modecfg_up. The script gets executed more than once because racoon processes multiple configure response packets from the gateway. Unlike other exchange modes, the configure mode lacks proper state handling which I believe to be the root cause of the issue. Gabriels patch just introduces state at the script execution level as opposed to the exchange packet processing level. It really isn't that much work to do this right and make it consistent with the other exchange modes. I will work up a patch over the weekend and forward it to the list for testing. -Matthew |