Hi Paul, My understanding of RFC4301 section 4.1, is that nodes supporting only unicast communications can index their SA only using the SPI while nodes supporting multicast communications must also use the IP addresses and thus SA lookup needs to be performed using the longest match.
I guess that multipurpose interoperability is achieved with the longest match lookup. But I agree I am also confused. Yours, Daniel -----Original Message----- From: paul.kon...@dell.com [mailto:paul.kon...@dell.com] Sent: Friday, March 24, 2017 4:25 PM To: Daniel Migault <daniel.miga...@ericsson.com> Subject: Re: [IPsec] Number of fixed SPI > On Mar 24, 2017, at 4:16 PM, Daniel Migault <daniel.miga...@ericsson.com> > wrote: > > Hi, > > I have a question regarding devices that are not able to randomly generate > SPI, but instead store fix values. The question is how much fix values could > be provisioned. > > For unicast communications, a single SPI can be used over multiple nodes as > long as the remote peer, as long as both nodes uses IP addresses and SPI to > index the SAs. With the transport mode, the number of SPI is equivalent to > the number of hosts, while with tunnel mode, the number of SPI is equivalent > to the number of tunnels. > For that reason I would recommend that a minimal implementation supporting > unicast only has as many SPI values as ESP session per host or per security > gateways, and that lookup includes the IP addresses. > > However this would not work with a security gateway that performs lookup only > based on the SPI. Such security gateway would still be ESP.compliant. I must be missing something. Maybe I'm remembering older documents. My understanding of ESP and the security architecture RFC is that lookup is required to be by SPI and IP address. Where do you see text that suggests SPI-only lookup is compliant? A principle of communication standards design is that conformance should imply interoperability, so if the RFC really does permit one node to send something that another node would not be able to handle, that would be an RFC bug. paul _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip
