Re: [IPsec] Comments on draft-pwouters-multi-sa-performance

[Paul Wouters <[e-mail]>]

On Fri, 29 Oct 2021, Panwei (William) wrote:

Hi William,

> Subject: [IPsec] Comments on draft-pwouters-multi-sa-performance

> I’ve read the recent version. This is an interesting solution. I think it should be adopted. Below are some comments.

Thnks for reading the draft and giving us feedback!

> 1.
> 
> The CPU_QUEUES notification value refers to the number of additional
> 
> resource-specific Child SAs that may be installed for this particular
> 
> TSi/TSr combination excluding the Fallback Child SA.
> 
> Is it necessary to limit the amount of additional SAs at the beginning while TS_MAX_QUEUE can be used to reject the request of
> creating additional SA at any time? In the virtualization scenario, the new VMs can be launched on-demand, in other words, it may be
> seen as the number of CPUs isn’t fixed, so maybe limiting the addition SAs at the beginning will damage the flexibility.

The limit is really a very high maximum number and not a very low number
exactly matching CPUs. We had that at first, to try and optimize it but
there were too many race conditions, eg with rekeying. So if you have
a peer with 4 CPUs and a peer with 2 CPUs, you might just want to set
the max to 8 or even 12. It is mostly meant to try and avoid doing
CREATE_CHILD_SA's that are just doomed to failure anyway. So see it
more as a resource cap that a strict physical limitation.

> 2.
> 
> The CPU_QUEUES notification payload is sent in the IKE_AUTH or
> 
> CREATE_CHILD_SA Exchange indicating the negotiated Child SA is a
> 
> Fallback SA.
> 
> Before additional SAs are created, is there any difference between using this first/Fallback SA and using other normal SA? I think
> there is no difference. So maybe we don’t need to add this notification payload when creating the first SA.

the problem right now is that implementations often will discard an
an older identical Child SA for the newest one. So one of the key
intentions of the document is for the initiator/responder to clearly
negotiate from the start they are going to be using Child SA's with
identical Traffic Selectors and they want the older ones to stick
around. Also, it is important that there is always 1 fallback Child
SA that can be used on any CPU resource. So we really wanted to mark
that one very clearly. For instance, if it becomes idle, it should
NOT be deleted.

> When the initiator wants
> to create an additional SA, it can directly send the request with CPU_QUEUE_INFO notification payload.

It would be good to know from the responder if they support this and if
they are willing to do this before doing the CREATE_CHILD_SA. And as I
said above, to ensure both parties agree on which Child SA is the
"always be present" fallback SA to ensure things like adding a new CPU
always results in encrypted packets via the fallback SA.

> There are 3 ways that the
> responder may reply: 1) The responder doesn’t support/recognize this notification, it will ignore this notification and reply as
> usual.

But there is no "as usual" for what happens to the older Child SA. Some
implementations will allow it, some will only allow it if it has its own
IKE SA, and some will just delete the old one. This is the ambiguity we
are trying to address with the draft.

> 2) It supports this function and is willing to create the additional SA, so it will reply with CPU_QUEUE_INFO notification
> too. 3) It supports this function, but it isn’t willing to create more additional SAs, so it will reply with TS_MAX_QUEUE.
> Therefore, it seems like that CPU_QUEUE_INFO and TS_MAX_QUEUE these 2 notifications are enough to use, and the draft can be
> simplified to only use these 2 notifications.

I hope I explained why we think some clear signal has its use. If you
take your assumptions to the max, one would need no document at all,
as the IKEv2 specification states there can be Child SAs that are
duplicates or with overlapping IP ranges, so in theory, nothing is
needed.

> 3.
> 
> Both peers send
> 
> the preferred minimum number of additional Child SAs to install.
> 
> First, I think sending the number of additional Child SAs is unnecessary. Second, when using “minimum” here my first impression is
> that it means 0, so in order to remove ambiguity I suggest just saying “the preferred number” (if you think sending the number is
> necessary).

The use of minimum is indicating what the peer needs. A peer with 4 CPUs
does not prefer 4, it really prefers as many as the highest number of
CPUs of the two peers - within reason. The preference is really a
combination of what works best for the combination of the two peers.

Note the minimum is not about the minimum number required for
functioning, but the minimum number to get optimum performance.

By indicating the minimum, both sides can pick the highest minimum and
then allow a few more (for race conditions during rekeying).

> 4.
> 
> If a CREATE_CHILD_SA exchange request containing both a
> CPU_QUEUE_INFO and a CPU_QUEUES notification is received, the
> responder MUST ignore the CPU_QUEUE_INFO payload. If a
> CREATE_CHILD_SA exchange reply is received with both CPU_QUEUE_INFO
> and CPU_QUEUES notifications, the initiator MUST ignore the
> notification that it did not send in the request.
> 
> I think there is ambiguity here. When the initiator sends the CREATE_CHILD_SA exchange request containing both a CPU_QUEUE_INFO and
> a CPU_QUEUES notification, and the responder also adds CPU_QUEUE_INFO and CPU_QUEUES notifications in the reply, the initiator
> doesn’t know how to process with this situation, should the initiator ignore the CPU_QUEUE_INFO payload or notify an error to the
> responder?

We went back and forth on this a couple of times with the authors. We
really wanted to keep it as simple as possible but also not be too
pedantic. From a protocol point of view, we could say to just return
an error like SYNTAX_ERROR, but that would cause the IKE SA and all
its working Child SAs to also be torn down, and we wanted to avoid
that so bugs in the performance implementation does not result in
completely tunnel failures. Hence our phrasing of "just ignore X"
on both the initiator and responder.

We agree that a broken initiator with a broken responder leads to
something broken. I think specifying how a broken initiator should
respond to a broken responder is taking the Postel Principle a step
too far? :)

Paul