On Thu, 2005-12-08 at 15:42 +0200, Pekka Savola wrote: > 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?
Yes, someone might say that I don't carefully read all the necessary documents. :) But, as we are at "auditable event" there is another question. IKEv2 draft specifies INVALID_SPI notify that should be sent in case ESP/AH packet is received with unknown SPI value. I assume that "auditable event" should be catched by IKE daemon that constructs notify. The question is: Is "auditable event" implemented, and how can be used by IKE daemon? I hope this one is not so obvious? > 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. Maybe someone more knowledgeable in kernel's network implementation could answer this. Stjepan Gros - 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
