netdev
[Top] [All Lists]

IPSec: can't get IPv6 IPSec working with racoon

To: NetDev Mailinglist <netdev@xxxxxxxxxxx>
Subject: IPSec: can't get IPv6 IPSec working with racoon
From: Felipe Alfaro Solana <felipe_alfaro@xxxxxxxxxxxxx>
Date: Wed, 25 Feb 2004 13:58:02 +0100
Cc: Kernel Mailinglist <linux-kernel@xxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
Hi!

I have been unable to make IPSecv6 work between two hosts running 2.6.3
kernels and racoon. It works perfectly with IPv4, but with IPv6 there
seems to be the following problem:

Host A and Host B are configured so any IPv6 and IPv6 packet exchange
MUST use ESP/AH:

1. Host A tries to send and ICMPv6 ping echo request to host B, but
since there exists a Security Policy that requires the use of ESP/AH,
before A can send the ICMPv6 echo request, it must trigger an SA
negotiation with host B. To start this SA negotiation, host A needs to
know the link-layer address of peer host B:
        1.1 Host A sends a Neighbor solicitation message to host B
        1.2 Host B tries to send a Neigbor discovery packet, but since
        there exists a Security Policy that requires the use of ESP/AH,
        before B can send the Neighbor discovery, it triggers SA
        negotiation.

This seems to create a loop: host A triggers SA negotiation in first
place, but needs to know link-layer address of B, thus it sends a
Neighbor solicitation packet which makes host B trigger SA association.
Thus, both hosts are trying to establish an SA association, creating a
deadlock.

With IPv4 and IPSec, the simplified packet trace is:

A -> B ISAKMP Security Association
B -> A ISAKMP Security Association
A -> B ISAKMP Key Exchange
B -> A ISAKMP Key Exchange
A -> B ISAKMP Identification
B -> A ISAKMP Identification

But, with IPv6 and IPSec, this is the packet trace I'm seeing:

A -> B ICMPv6 Neighbor solicitation
A -> B ICMPv6 Neighbor solicitation
B -> A ISAKMP Security Association (initiator)
A -> B ICMPv6 Neighbor solicitation
A -> B ICMPv6 Neighbor solicitation
...

Let be host A configured with the following IPv6 address:

        inet addr   192.168.0.100
        inet6 addr: fec0::204:75ff:feab:6fcc/64 Scope:Site
        inet6 addr: 2000::204:75ff:feab:6fcc/64 Scope:Global
        inet6 addr: fe80::204:75ff:feab:6fcc/64 Scope:Link

Let be host B configured with the following IPv6 addresses:

        inet addr   192.168.0.2
        inet6 addr: fec0::2/64 Scope:Site
        inet6 addr: 2000::204:75ff:fe75:9765/64 Scope:Global
        inet6 addr: fe80::204:75ff:fe75:9765/64 Scope:Link

I'm using the following setkey commands on host A:

flush;
spdflush;
spdadd 192.168.0.100 192.168.0.2 any -P out ipsec esp/transport//require
ah/transport//require;
spdadd 192.168.0.2 192.168.0.100 any -P in ipsec esp/transport//require
ah/transport//require;
spdadd fec0::204:75ff:feab:6fcc fec0::2 any -P out ipsec
esp/transport//require ah/transport//require;
spdadd fec0::2 fec0::204:75ff:feab:6fcc any -P in  ipsec
esp/transport//require ah/transport//require;

The same commands (reversing the order) are applied on host B.

I'm running 2.6.3 and racoon on both hosts. IPSec over IPv4 works
perfectly, but does not work over IPv6. I trigger the IPSecv6
negotiation by doing a ping6 from host A to host B.

Am I right when I think there is a deadlock when negotiating the
Security Association between host A and host B? I've attached a trace
for IPv4 for a complete IPSec SA establishment, and a trace for IPv6
(which doesn't work).

Attachment: IPv4
Description: Binary data

Attachment: IPv6
Description: Binary data

<Prev in Thread] Current Thread [Next in Thread>