[strongSwan-dev] FW: rationale of reqid update on responder side

Tue May 28 17:02:12 CEST 2013

Hi Martin, Christophe,

I have also similar kind of problem posted long time back. But, i didn't
get any update on my query.

Looks, Both are discussing the similar problem. Please provide your
comments.

Strongswan Version: Linux strongSwan U4.5.0/K2.6.32.58

I am facing the issue in allocating the req id for IPSec tunnel and Policy.

If we have both the side become a initiator then two SA (in & out) tunnels
created for Single SP.

"reqid" is mismatching between SA and SP.

Node A <------------> Node B

Tunnel established between Node A and Node B.

I am sending the Ping from Node A to Node B and its failing.

Sender Side: (PING Request)
=========================

root at 10:~ >ping -I 2.2.2.2 12.12.12.12
PING 12.12.12.12 (12.12.12.12) from 2.2.2.2 : 56(84) bytes of data.
01:21:03.207543 IP 10.10.10.10 > 10.10.10.11: ESP(spi=0xc869e935,seq=0x1f),
length 96
01:21:04.208366 IP 10.10.10.10 > 10.10.10.11: ESP(spi=0xc869e935,seq=0x20),
length 96

Security Association Table:
========================
root at 10:~ >ip x s
src 10.10.10.10 dst 10.10.10.11
proto esp spi 0xc869e935 reqid 1 mode tunnel
replay-window 0 flag 20
auth hmac(sha1) 0x000e5af11f3ff6385af7c1452e1e472b5e997f16
enc cbc(aes) 0x6eca8ddfa393bb18207de3e75e60bd1d
src 10.10.10.11 dst 10.10.10.10
proto esp spi 0xc699d2d5 reqid 1 mode tunnel
replay-window 0 flag 20
auth hmac(sha1) 0xc8b39b92ac18c211f5eb32cd6d7d9e10095b0413
enc cbc(aes) 0x4997e1f2a391bfdaf1e251fcd18eafd7
src 10.10.10.10 dst 10.10.10.11
proto esp spi 0xc6c50120 reqid 2 mode tunnel
replay-window 0 flag 20
auth hmac(sha1) 0xf132e706c40deeda21e9147f2dee624423468fa0
enc cbc(aes) 0xafdf0fa8e923e35112ace1975044cc75
src 10.10.10.11 dst 10.10.10.10
proto esp spi 0xc599369c reqid 2 mode tunnel
replay-window 0 flag 20
auth hmac(sha1) 0xbf6a1a52216d4daebb5bb18f9b84e119a7248c9e
enc cbc(aes) 0xed45eb6c03ae379b0c51c6739fb74bf9
root at 10:~ >

Receiver Side:
=============
root at 10:~ >01:23:28.005013 IP 10.10.10.10 > 10.10.10.11:
ESP(spi=0xc869e935,seq=0x22),
length 94
01:23:28.005090 IP 2.2.2.2 > 12.12.12.12: ICMP echo request, id 10901, seq
1, length 64

Security Association:
=================
root at 10:~ >ip x s
src 10.10.10.11 dst 10.10.10.10
proto esp spi 0xc599369c reqid 1 mode tunnel
replay-window 0 flag 20
auth hmac(sha1) 0xbf6a1a52216d4daebb5bb18f9b84e119a7248c9e
enc cbc(aes) 0xed45eb6c03ae379b0c51c6739fb74bf9
src 10.10.10.10 dst 10.10.10.11
proto esp spi 0xc6c50120 reqid 1 mode tunnel
replay-window 0 flag 20
auth hmac(sha1) 0xf132e706c40deeda21e9147f2dee624423468fa0
enc cbc(aes) 0xafdf0fa8e923e35112ace1975044cc75
src 10.10.10.11 dst 10.10.10.10
proto esp spi 0xc699d2d5 reqid 2 mode tunnel
replay-window 0 flag 20
auth hmac(sha1) 0xc8b39b92ac18c211f5eb32cd6d7d9e10095b0413
enc cbc(aes) 0x4997e1f2a391bfdaf1e251fcd18eafd7
src 10.10.10.10 dst 10.10.10.11
proto esp spi 0xc869e935 reqid 2 mode tunnel
replay-window 0 flag 20
auth hmac(sha1) 0x000e5af11f3ff6385af7c1452e1e472b5e997f16
enc cbc(aes) 0x6eca8ddfa393bb18207de3e75e60bd1d

Security Policy:
=============
root at 10:~ >ip x p
src 2.2.2.2/32 dst 12.12.12.12/32
dir fwd priority 1
tmpl src 10.10.10.10 dst 10.10.10.11
proto esp reqid 1 mode tunnel
src 2.2.2.2/32 dst 12.12.12.12/32
dir in priority 1
tmpl src 10.10.10.10 dst 10.10.10.11
proto esp reqid 1 mode tunnel
src 12.12.12.12/32 dst 2.2.2.2/32
dir out priority 1
tmpl src 10.10.10.11 dst 10.10.10.10
proto esp reqid 1 mode tunnel

root at 10:~ >cat /proc/net/xfrm_stat
XfrmInError 0
XfrmInBufferError 0
XfrmInHdrError 0
XfrmInNoStates 10
XfrmInStateProtoError 0
XfrmInStateModeError 0
XfrmInStateSeqError 0
XfrmInStateExpired 0
XfrmInStateMismatch 0
XfrmInStateInvalid 0
XfrmInTmplMismatch 121
XfrmInNoPols 0
XfrmInPolBlock 0

Thanks.
Jegathesh

> Sent: Thursday, May 23, 2013 1:17 PM
> To: Christophe Gouault
> Cc: dev at lists.strongswan.org
> Subject: Re: [strongSwan-dev] rationale of reqid update on responder side
>
>
> > Does this mean we decide to give up older SAs as soon as we establish a
> new
> > CHILD_SA as responder? This may not be what the remote peer wants
> (otherwise
> > it would have *rekeyed* the SA instead).
>
> No. It means that two different CHILD_SAs triggered from the same trap
> policy use the same reqid.
>
> Assuming a trap policy to 10.0.0.0/16, and traffic to 10.0.1.1 triggers
> an SA. The responder, however, narrows the traffic selector to
> 10.0.1.0/24. Now you have traffic to 10.0.2.1, which triggers another
> CHILD_SA, which might get narrowed by the responder to 10.0.2.0/24.
>
> So you'll have two CHILD_SA with the same reqid (that of the trap
> policy). This is problematic for the kernel, which uses the reqid to map
> policies to SAs.
>
> > According to what I observed, the trap CHILD_SA is left unchanged, but
> > the policy in the kernel is updated with the new CHILD_SA reqid (I agree
> > that itis necessary if we want the SA to be used).
> >
> > However, the trap CHILD_SA becomes unusable because it mismatches the
> > policy reqid.
>
> Yes. Because we can't have two identical policies in XFRM, we use
> refcounting to install it only once. This doesn't work for different
> reqids, as only one reqid can be active for these refcounted policies.
>
> This is why we reuse the reqid of a trap policy when installing an SA
> triggered by it. And this is what we should do when we install an SA as
> responder for which we have a trap installed.
>
> Regards
> Martin
>
>
> _______________________________________________
> Dev mailing list
> Dev at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20130528/b5473daf/attachment.html>