netdev - Possible solution to those doubly created SAs in ipsec

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <1174433558.3085.236.camel@faith.austin.ibm.com>
Date:	Tue, 20 Mar 2007 17:32:38 -0600
From:	Joy Latten <latten@...tin.ibm.com>
To:	netdev@...r.kernel.org
Cc:	paul.moore@...com, eparis@...hat.com, herbert@...dor.apana.org.au,
	vyekkirala@...stedCS.com, jmorris@...ei.org, davem@...emloft.net
Subject: Possible solution to those doubly created SAs in ipsec

A while back I reported that I sometimes saw double and triple 
SAs being created. The patch to check for protocol when deleting
larval SA removed one obstacle in that I no longer see triple SAs. 
Now, once in a while double SAs. I think I have figured out the
second obstacle.

The initiator installs his SAs into the kernel before the responder.
As soon as they are installed, the blocked packet (which started
the ACQUIRE) is sent. By this time the responder has installed his
inbound SA(s) and so the newly arrived ipsec packet can be processed.
In the case of tcp connections and a ping, a response may be 
warranted, and thus an outgoing packet results. 

>>From what I can tell of the log file below, sometimes, this
might happen before the responder has completed installing 
the outbound SAs. In the log file, the outbound AH has been added, 
but not the outbound ESP, which is the one the outgoing packet 
looks for first. Thus resulting in a second acquire. 

I think this becomes more problematic when using both AH AND ESP, 
rather than just using ESP with authentication. With the latter, 
only one SA needed thus reducing the latency in installing the 
SAs before incoming packet arrives.     

So far, the only solution I can think of besides mandating all 
userspace key daemons do SA maintenance is to perhaps add larval 
SAs for both directions when adding the SPI. Currently, responder 
does GETSPI for one way and initiator for opposite. When GETSPI is
called, larval SA is created containing the SPI, but it is only 
for one direction. Perhaps we can add a larval SA (no SPI) for 
opposite direction to act as a placeholder indicating ACQUIRE 
occurring, since SAs are created for both directions during an ACQUIRE.
The initiator may have larval SA from GETSPI and larval SA from the
ACQUIRE depending that GETSPI is in opposite direction of ACQUIRE.
Calling __find_acq_core() should ensure we don't create duplicate 
larval SAs. Also, should IKE negotiations return error, larval SAs
should expire. They also should be removed when we do the
xfrm_state_add() and xfrm_state_update() to add the new SAs.

If this is not a good idea or there is a better way to do this, please
let me know. I wanted to ask before coding and testing in case
there is a better solution and I won't have wasted time.

Regards,
Joy  

mylogfile (it has been cut and pasted, so irrelevant sections left out)

2007-03-20 13:39:04: DEBUG: pfkey UPDATE succeeded: AH/Transport 
x.x.x.210[0]->x.x.x.55[0] spi=203125341(0xc1b725d) 

2007-03-20 13:39:04: INFO: IPsec-SA established: AH/Transport
x.x.x.210[0]->x.x.x.55[0] spi=203125341(0xc1b725d)

2007-03-20 13:39:04: DEBUG: pfkey UPDATE succeeded: ESP/Transport
x.x.x.210[0]->x.x.x.55[0] spi=157349023(0x960f49f)

2007-03-20 13:39:04: INFO: IPsec-SA established: ESP/Transport
x.x.x.210[0]->x.x.x.55[0] spi=157349023(0x960f49f)

2007-03-20 13:39:04: DEBUG: ===

2007-03-20 13:39:04: DEBUG: get pfkey ADD message

2007-03-20 13:39:04: INFO: IPsec-SA established: AH/Transport
x.x.x.55[0]->x.x.x.x.210[0] spi=196161037(0xbb12e0d)

2007-03-20 13:39:04: DEBUG: ===

2007-03-20 13:39:04: DEBUG: get pfkey ACQUIRE message

2007-03-20 13:39:04: DEBUG: call pfkey_send_getspi

2007-03-20 13:39:04: DEBUG: pfkey GETSPI sent: AH/Transport
x.x.x.210[0]->x.x.x.55[0]

2007-03-20 13:39:04: DEBUG: call pfkey_send_getspi

2007-03-20 13:39:04: DEBUG: pfkey GETSPI sent: ESP/Transport
x.x.x.210[0]->x.x.x.55[0]

2007-03-20 13:39:04: DEBUG: pfkey getspi sent.

2007-03-20 13:39:04: DEBUG: get pfkey ADD message

2007-03-20 13:39:04: INFO: IPsec-SA established: ESP/Transport
x.x.x.55[0]->x.x.x.210[0] spi=241180149(0xe601df5)

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html