On 8/3/20 4:17 AM, Michael Rossberg wrote:
Unfortunately I develop systems for a customer who uses DS for some (maybe
non-technical)
reason.
Helpful to not use abbreviations. DS = storage Data Servers? AWS Directory
Service?
Microsoft Domain Services?
The issue I am struggling with: If there are multiple “reasons” to allocate
blocks of SAs we’ll
have a lot of unused SPI space. Coming back to my example data center scenario:
Customer
with 10,000 VMs doing multicast + QoS + having multiple cores (say AMD with 64).
You know of a VM doing multiple bulk multicast tasks at the same time?
10,000 VMs sending multicast? Or receiving?
As senders, 10,000 VMs would each have their own IP address; multicast senders
don't
use the multicast address as Source.
Even in my wildest dreams, I'm finding it hard to envision 10,000 replicated
data
storage VMs. But in that case, they'd be receiving (object updates).
So no matter how many cores, there shouldn't be more than that many multicast
SPIs.
(Or unicast SPIs for that matter.)
One way out is Tero’s suggestion to add the sender IP address to the SA lookup.
Yep, several of us have mentioned this. My understanding was to check the
Sequence
Number for replay attacks, and for implicit IV generation.
Most prominently there maybe issues with
IPv6 renumbering and multiple/non-unique sender IP addresses.
The stated reason for needing extra fields was to differentiate senders within
the
same implicit IV space. Renumbering won't hurt that. Indeed, would help!
AFAIK, multicast sender non-unique Source IP addresses isn't allowed either.
Are you planning on 10,000 VMs somehow sharing the same Source IP address?
Furthermore, the IP addresses
of the senders would required to be known in advance.
Why? Again, it's just to keep the Sequence Numbers separate to avoid duplicate
implicit IVs under the same secret. Define it algorithmically. No state.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
