Hi Michael,
> One way out is Tero’s suggestion to add the sender IP address to the SA
> lookup.
If you properly implement ESP, than you must have already included
source IP for SA lookup. It was explicitly added to cover Source-specific
Multicast use case.
And in case of SSM source addresses are not unique (however, all the drafts
covering
SSM are long expired, so I'm not sure it's widely or ever used).
>From RFC4303, Section 2.1:
Each entry in the Security Association Database (SAD) [Ken-Arch] must
indicate whether the SA lookup makes use of the destination, or
destination and source, IP addresses, in addition to the SPI. For
multicast SAs, the protocol field is not employed for SA lookups.
For each inbound, IPsec-protected packet, an implementation must
conduct its search of the SAD such that it finds the entry that
matches the "longest" SA identifier. In this context, if two or more
SAD entries match based on the SPI value, then the entry that also
matches based on destination, or destination and source, address
comparison (as indicated in the SAD entry) is the "longest" match.
This implies a logical ordering of the SAD search as follows:
1. Search the SAD for a match on {SPI, destination address,
source address}. If an SAD entry matches, then process the
inbound ESP packet with that matching SAD entry. Otherwise,
proceed to step 2.
2. Search the SAD for a match on {SPI, destination address}.
If the SAD entry matches, then process the inbound ESP
packet with that matching SAD entry. Otherwise, proceed to
step 3.
3. Search the SAD for a match on only {SPI} if the receiver has
chosen to maintain a single SPI space for AH and ESP, or on
{SPI, protocol} otherwise. If an SAD entry matches, then
process the inbound ESP packet with that matching SAD entry.
Otherwise, discard the packet and log an auditable event.
Regards,
Valery.
> I have thought
> about this option over the last days, but I am coming more and more to the
> conclusion that
> this is left out of the lookup for a couple of reasons: Most prominently
> there maybe issues with
> IPv6 renumbering and multiple/non-unique sender IP addresses. Furthermore,
> the IP addresses
> of the senders would required to be known in advance. All of this will cause
> a lot of control
> plane overhead and possible race conditions in the interworking between
> control and data
> plane.
>
>
>
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
