Brian
Brian Buesker wrote:
There are four entries all together in the SPD, 2 for inbound traffic and 2 for outbound. Here is the output of setkey -DP with the IPv6 addresses represented by A and B.
B[2000] A[3000] udp
in ipsec
esp/transport//unique#16457
created: Aug 25 08:06:15 2003 lastused: lifetime: 0(s) validtime: 0(s)
spid=13464 seq=19 pid=20448
refcnt=1
B[2000] A[3500] udp
in ipsec
ah/transport//unique#16459
created: Aug 25 08:06:15 2003 lastused: lifetime: 0(s) validtime: 0(s)
spid=13480 seq=18 pid=20448
refcnt=1
A[3000] B[2000] udp
out ipsec
esp/transport//unique#16456
created: Aug 25 08:06:15 2003 lastused: lifetime: 0(s) validtime: 0(s)
spid=13457 seq=17 pid=20448
refcnt=1
A[3500] B[2000] udp
out ipsec
ah/transport//unique#16458
created: Aug 25 08:06:15 2003 lastused: lifetime: 0(s) validtime: 0(s)
spid=13473 seq=16 pid=20448
refcnt=1
0.0.0.0/0[any] 0.0.0.0/0[any] any
in none
created: Aug 22 17:21:40 2003 lastused: lifetime: 0(s) validtime: 0(s)
spid=13443 seq=15 pid=20448
refcnt=2
0.0.0.0/0[any] 0.0.0.0/0[any] any
in none
created: Aug 22 17:21:40 2003 lastused: lifetime: 0(s) validtime: 0(s)
spid=13427 seq=14 pid=20448
refcnt=2
::/0[any] ::/0[any] any
in none
created: Aug 22 17:21:40 2003 lastused: lifetime: 0(s) validtime: 0(s)
spid=13411 seq=13 pid=20448
refcnt=2
::/0[any] ::/0[any] any
in none
created: Aug 22 17:21:40 2003 lastused: Aug 22 17:21:44 2003
lifetime: 0(s) validtime: 0(s)
spid=13395 seq=12 pid=20448
refcnt=2
::/0[any] ::/0[any] any
in none
created: Aug 22 17:21:40 2003 lastused: lifetime: 0(s) validtime: 0(s)
spid=13379 seq=11 pid=20448
refcnt=2
::/0[any] ::/0[any] any
in none
created: Aug 22 17:21:40 2003 lastused: lifetime: 0(s) validtime: 0(s)
spid=13363 seq=10 pid=20448
refcnt=2
::/0[any] ::/0[any] any
in none
created: Aug 22 17:21:40 2003 lastused: lifetime: 0(s) validtime: 0(s)
spid=13347 seq=9 pid=20448
refcnt=2
::/0[any] ::/0[any] any
in none
created: Aug 22 17:21:40 2003 lastused: lifetime: 0(s) validtime: 0(s)
spid=13315 seq=8 pid=20448
refcnt=2
0.0.0.0/0[any] 0.0.0.0/0[any] any
out none
created: Aug 22 17:21:40 2003 lastused: lifetime: 0(s) validtime: 0(s)
spid=13452 seq=7 pid=20448
refcnt=2
0.0.0.0/0[any] 0.0.0.0/0[any] any
out none
created: Aug 22 17:21:40 2003 lastused: lifetime: 0(s) validtime: 0(s)
spid=13436 seq=6 pid=20448
refcnt=2
::/0[any] ::/0[any] any
out none
created: Aug 22 17:21:40 2003 lastused: lifetime: 0(s) validtime: 0(s)
spid=13420 seq=5 pid=20448
refcnt=2
::/0[any] ::/0[any] any
out none
created: Aug 22 17:21:40 2003 lastused: Aug 22 17:21:44 2003
lifetime: 0(s) validtime: 0(s)
spid=13404 seq=4 pid=20448
refcnt=2
::/0[any] ::/0[any] any
out none
created: Aug 22 17:21:40 2003 lastused: lifetime: 0(s) validtime: 0(s)
spid=13388 seq=3 pid=20448
refcnt=2
::/0[any] ::/0[any] any
out none
created: Aug 22 17:21:40 2003 lastused: lifetime: 0(s) validtime: 0(s)
spid=13372 seq=2 pid=20448
refcnt=2
::/0[any] ::/0[any] any
out none
created: Aug 22 17:21:40 2003 lastused: lifetime: 0(s) validtime: 0(s)
spid=13356 seq=1 pid=20448
refcnt=2
::/0[any] ::/0[any] any
out none
created: Aug 22 17:21:40 2003 lastused: lifetime: 0(s) validtime: 0(s)
spid=13324 seq=0 pid=20448
refcnt=2
Racoon does negotiate the security associations for both AH and ESP in both directions (as can be seen by doing setkey -D), but for some reason the wrong SA is being used on one end. Do you think this is this a kernel problem, or something wrong with the way Racoon is inserting the security associations into the SADB?
Brian
Jean-Francois Dive wrote:
as far as i thought, racoon did not supported fine grained selectors (i am note sure as i dont use racoon). Which entries are in the SPD ? )
On Fri, 2003-08-22 at 18:14, Brian Buesker wrote:
While doing some more IPsec testing on 2.6.0-test2 with Racoon as the IKE daemon, I came across the following behavior which does not seem correct. I was trying to have two different security associations between the same pair of hosts, where the traffic between one UDP port pair is protected with ESP, and the traffic between a different UDP port pair is protected with AH. For example, if A and B are the IPv6 addresses of the two hosts, then I was trying to get A:3000 <-> B:2000 protected with ESP, and A:3500 <-> B:2000 protected with AH. I have used the unique level for all of the SPD entries. As far as I can tell, the IKE daemon is correctly triggered and establishes the security associations correctly. In other words, there are two quick mode exchanges. Using setkey -D shows 4 security associations, two ESP ones and two AH ones with the appropriate end points. However, for whichever SA that is established second, the reply packets use the incorrect security association. For example, if the first security association established is the A:3000 <-> B:2000 with ESP, then all of this traffic is correctly protected by ESP, and traffic between A:3500 -> B:2000 is protected by AH. However, from B:2000 -> A:3500, the ESP SA for B:2000 -> A:3000 is applied instead of the AH one. It seems that the kernel is selecting the wrong SA to use to protect this traffic.
By the way, I tried the exact same setup using IPv4 addresses instead, and this problem did not occur. Any ideas on why this would be?
Brian
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
- : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
- : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
