Thank you for the clarification. My initial problem was if multiple nodes connects with the same SPI to a gateway, does the gateway needs some specific ways to lookup. As mentioned by Tero, this is not the case as the SPI is not used for inbound traffic by the gateway. The limitation due to a limited number of SPI are on the node side.Thanks!
On Sun, Mar 26, 2017 at 1:45 PM, Tero Kivinen <kivi...@iki.fi> wrote: > Daniel Migault writes: > > 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. Does it sounds reasonable that security gateways > > implements the longest match lookup or at least lookup considering > > IP addresses ? > > ESP SPI is allocated by the receiving host. It is up to the node > receiving the ESP packets with SPI it gave out to decide how the SPI > is allocated, and used. > > The sender can have multiple SAs going out each having same outbound > SPI, and that does not cause any issues. The receiver will either have > unique SPI for each Child SA, or it might use SPI with combination of > the protocol number (AH or ESP), or it might even use the destination > address (i.e., its own address or multicast address) etc. > > But there is no issues in there, as the node who does the receiving > is also the same node who allocates the SPIs, so he can enforce his > own rules on the SPI allocatons, and the other end does not need to > know those rules. > -- > kivi...@iki.fi > > _______________________________________________ > Lwip mailing list > Lwip@ietf.org > https://www.ietf.org/mailman/listinfo/lwip >
_______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip
