On Thu, 8 Dec 2005, Stjepan Gros wrote:
I have a problem with kernel's behavior when receiving ESP/AH packets
with unknown SPI values.
As it turns out, when such a packet arrives, kernel simply discards it.
The consequence is that in some tests first packet is lost. For example,
trying to ping other side the 0th packet will be sent, but all the
others will go alright. In other words, there is basically a race
between ICMP packet coming to machine, and IKE daemon on that machine
that is installing SAs.
Am I right? Can anything be done about it?
Page 59 of
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2401bis-06.txt
says:
3a. If the packet is addressed to the IPsec device and AH or ESP is
specified as the protocol, the packet is looked up in the SAD. For
unicast traffic, use only the SPI (or SPI plus protocol). For
multicast traffic, use the SPI plus the destination or SPI plus
destination and source addresses, as specified in section 4.1. In
either case (unicast or multicast), if there is no match, discard
the traffic. This is an auditable event. The audit log entry for
this event SHOULD include the current date/time, SPI, source and
destination of the packet, IPsec protocol, and any other selector
values of the packet that are available. If the packet is found
in the SAD, process it accordingly (see step 4).
.. so it seems to me that packets with unknown SPI values should be
thrown away?
So, it seems that what you're looking for is support for opportunistic
encryption; see section 3.1 of
draft-richardson-ipsec-opportunistic-17.txt
I'm not sure if Linux kernel purports to do that.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
