Any ideas?
2012/2/2 Daniel Palomares <[email protected]> > Well, > I achieved to change ESP sequence manually by changing > kernel_netlink_ipsec.c as I told on my first email. > > I realized that packets changed their ESP Sequence counter to the number I > wanted to thanks to wireshark. > Now my question is, how can you ask the kernel what is the value of the > ESP sequence counter at anytime? > > Do you know if "setkey" or "ip xfrm" are the appropriate commands? > If yes: could you be explicit by telling what is the correct command that > tells what is the value of the ESP sequence counters for each SA?. > > Thanks in advance again! > > Daniel > > > 2012/2/1 Daniel Palomares <[email protected]> > >> Concerning last email; >> >> I have noticed that during 'add_sa' METHOD in kernel_netlink_ipsec.c , >> there is a structure called xfrm_usersa_info where all SA information is >> stored before sending it to kernel. >> Is it possible to change manually the unsingned int "__u32 seq" in order >> to establish this parameter manually? >> >> I have tried to change others parameters manually and It works (i.e. >> changing the "__u32 reqid" by setting it to 4 or 10 etc...), but not with >> "seq". >> >> Thanks, >> >> Daniel >> >> >> >> >> 2012/1/31 Daniel Palomares <[email protected]> >> >>> Hi All; >>> >>> I’m trying to do “roughly”, an IPsec context recovery for High >>> Availability purposes and testing. I know that there is a RFC already done, >>> by the way I wanted to learn how to manipulate ESP Sequence. >>> >>> What I do is the following: >>> - I establish a Transport Mode tunnel between a host and a gateway >>> (done as any IKEv2 implementation would do). >>> - Then, on the gateway side, I erase the whole IPsec information >>> concerning the SAs and Child’s and then I reinstall it again in the same >>> gateway. (I coded this by myself on Strongswan). >>> - During reinstallation of the SA, the only parameter that I’m >>> missing is the ESP Sequences. >>> >>> In order to establish this Sequence manually through the netlink message >>> attributes I found that XFRMA_REPLAY_VAL would be the appropriate type to >>> do so. >>> >>> The struct xfrm_replay_state should be modified in order to establish >>> these values manually. I’m I right? >>> >>> What I tried was something like taking a random number (i.e. 14) and I >>> wanted the reinstalled SA to have the ESP Sequence number 14 (just to tet >>> how to manually change ESP Sequences) >>> >>> xfrm_replay_state replay; >>> >>> replay.seq = 14; >>> replay.oseq =14; >>> replay.bitmap = (Didn’t know which value to use) >>> >>> I did take some implementation from strongswan: >>> >>> +++++++++++++++++++++++++++++++++++++++++ >>> (This is added when installing the new SA in kernel_netlink_ipsec.c) >>> >>> (This is not going to be the case for all new SAs established, as I told >>> before, I just want to know how to manipulate these ESP sequences manually) >>> >>> rthdr->rta_type = XFRMA_REPLAY_VAL; >>> rthdr->rta_len= RTA_LENGTH(sizeof(struct xfrm_replay_state)); >>> if(hdr->nlmsg_len > sizeof(request)) >>> { >>> return FAILED; >>> } >>> memcpy(RTA_DATA(rthdr, &replay, sizeof(replay)); >>> rthdr=XFRM_RTA_NEXT(rthdr); >>> >>> ++++++++++++++++++++++++++++++++++++++++++ >>> >>> I think this piece of code is supposed to add the ESP Sequence manually >>> when sending the message through the socket_xfrm. >>> >>> The SAD and SPD are installed correctly but not the ESP Sequence. >>> >>> Any ideas? >>> >>> >>> Cheers; >>> >>> Daniel >>> >> >> >
_______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
