Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance passed
Paul Wouters writes: > On Mon, 20 Nov 2023, Tero Kivinen wrote: > > > After some probing in the Prague, we managed to get good discussion > > and reviews on this draft, and I think the consensus on the list was > > that it should be ready to go forward. > > Note that we are still discussing on the list with Valery on a few > items, so I do expect to do at least one more draft version. At > which point you can either repeat a WGLC or send it to Roman. Thats ok, I can most likely will not be able to start my writeup before that anyways, and there might be some things that needs changeing after my review anyways. > > The adoption calls are still waiting for our security AD to respond, > > but I will start the ones listed on our charter when I get back > > Finland on Wednesday. > > These are about other drafts not mentioned in the subject line I guess? > Note Roman is mostly the last two weeks of November (American Thanksgiving > and all) so his responses might be a bit slower. I wam talking about draft-smyslov-ipsecme-ikev2-qr-alt, draft-mglt-ipsecme-diet-esp, draft-mglt-ipsecme-ikev2-diet-esp-extension. Last two are mentioned in the charter, and the first is continuation of our post quantum work, so I will start WG adoption calls after I get back to Finland. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance passed
On Mon, 20 Nov 2023, Tero Kivinen wrote: After some probing in the Prague, we managed to get good discussion and reviews on this draft, and I think the consensus on the list was that it should be ready to go forward. Note that we are still discussing on the list with Valery on a few items, so I do expect to do at least one more draft version. At which point you can either repeat a WGLC or send it to Roman. The adoption calls are still waiting for our security AD to respond, but I will start the ones listed on our charter when I get back Finland on Wednesday. These are about other drafts not mentioned in the subject line I guess? Note Roman is mostly the last two weeks of November (American Thanksgiving and all) so his responses might be a bit slower. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance
Hi Paul, I snipped parts where we are in agreement. > > 2. Section 2 > > > > There are a number of practical reasons why most Implementations have > > to limit a Child SA to only one specific hardware resource, but a key > > limitation is that sharing the crypto state, counters and sequence > > numbers between multiple CPUs is not feasible without a significant > > performance penalty. > > > > Shouldn't it be clarified, that the performance problems arise > > if you use an SA by several CPUs at the same time? I don't think > > there are problems if you use the SA by several CPUs at different time. > > Consider you have an SA with a traffic one packet per hour. > > Each time it is processed up by a different CPU, then the resulted > > state is stored in the shared memory. So, perhaps > > > > s/one specific hardware resource/one specific hardware resource at any > > given time > > I changed it to: > > but a key limitation is that sharing the crypto state, counters > and sequence numbers between multiple CPUs that are trying to > use these shared states at the same time is not feasible without > a significant performance penalty. Fine with me. > > 3. Section 3 > > > > If multiple Child SAs with the same Traffic Selectors are > > desired, the initiator will add the SA_RESOURCE_INFO notify payload > > to the Exchange negotiating the Child SA (eg IKE_AUTH or > > CREATE_CHILD_SA). If this initial Child SA will be tied to a > > specific resource, it MAY indicate this by including an identifier in > > the Notification Data. A responder that is willing to have multple > > Child SAs for the same Traffic Selectors will respond by also adding > > the SA_RESOURCE_INFO notify payload in which it MAY add a non-zero > > notify data payload. > > > > This text is a bit inconsistent with IKEv2 specification. > > In my reading the text implies that unless you exchange SA_RESOURCE_INFO, > > you cannot initiate multiple SAs with same selector, which is wrong - > > you can do it at any time if you follow RFC 7296. > > Only if you want to follow this draft (i.e. - associate each Child SA with > > some resource, and be able to limit their number with TS_MAX_QUEUE) > > you have to negotiate. I think that this subtle thing should be expressed > > more accurately. > > Changed to: > > If multiple Child SAs with the same Traffic Selectors that > are bound to a single resource are desired, [...] OK. > > 4. Section 3 > > > > These resource- > > specific Child SAs MUST be negotiated with identical Child SA > > properties that were negotiated for the initial Child SA. This > > includes cryptographic algorithms, Traffic Selectors, Mode (e.g. > > transport mode), compression usage, etc. However, each Child SA does > > have its own keying material that is individually derived according > > to the regular IKEv2 process. > > > > I think that MUST is over-restrictive if we talk about crypto algorithms. > > For crypto algorithms herhaps something along the lines: > > > > SHOULD be negotiated with the same crypto algorithms; > > if they differ, then they MUST provide identical level of protection. > > I don't agree. We are basically making "clones", so I see no reason why > to make this more complicated by allowing things to be more different in > various ways. The negotiation for the first child and second child > should follow from the same configuration so it should really also end > up returning the same crypto algorithms. Unless you would make choics > based on trigger packet on specific resource, but that's something I > am happy to not create another knob for. If others really feel similar > to Valery, please speak out. We would also than need to make a clear > list of all the knobs that MUST be the same and all the ones that SHOULD > be the same. I'd rather not make that list :P I see your point. I don't insist, but also don't want to eliminate this option. For example (as it was pointed out on the list) when different resources are optimized for different algorithms. > > (I agree that Mode and Traffic Selectors MUST be the same, not sure about > > compression). > > > > 5. Section 3 > > > > During the CREATE_CHILD_SA rekey for the Child SA, the > > SA_RESOURCE_INFO notification MAY be included, but regardless of > > whether or not it is included, the rekeyed Child SA MUST be bound to > > the same resource(s) as the Child SA that is being rekeyed. > > > > Isn't binding a local matter? Doesn't peer bother to what resource you bound > > your end of an SA? Then why is there this MUST? What happens if I bound new > > SA > > to a different CPU - peer never know this, so how it will check that you > > follow this MUST? > > I think that instead of this requirement there should be just a > > recommendation for implementers > > (with no BCP14 language). > i > changed MUST to should. I can live with this, although I would prefer
Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance
On Tue, 14 Nov 2023, Valery Smyslov wrote: I support publication of this draft. I'm glad authors took my points into consideration while preparing the latest version. I do have some comments though. 1. Section 1 IKEv2 [RFC7296] already allows installing multiple Child SAs with identical Traffic Selectors, but it offers no method to indicate that the additional Child SA is being requested for performance increase reasons and is restricted to some resource (queue or CPU). Without this indication, the peer might not accept multi Child SAs with identical Traffic Selectors and might delete one of the Child SAs it considered an unwanted duplicate. There is some inconsistency here. You first say that IKEv2 allows creating multiple identical Child SAs and then say that implementations would delete them as unwanted duplicates. Clearly these implementations violate RFC 7296, and we don't consider broken implementations, do we? :-) I suggest to remove the last sentence, or to add a clarification. Done. 2. Section 2 There are a number of practical reasons why most Implementations have to limit a Child SA to only one specific hardware resource, but a key limitation is that sharing the crypto state, counters and sequence numbers between multiple CPUs is not feasible without a significant performance penalty. Shouldn't it be clarified, that the performance problems arise if you use an SA by several CPUs at the same time? I don't think there are problems if you use the SA by several CPUs at different time. Consider you have an SA with a traffic one packet per hour. Each time it is processed up by a different CPU, then the resulted state is stored in the shared memory. So, perhaps s/one specific hardware resource/one specific hardware resource at any given time I changed it to: but a key limitation is that sharing the crypto state, counters and sequence numbers between multiple CPUs that are trying to use these shared states at the same time is not feasible without a significant performance penalty. 3. Section 3 If multiple Child SAs with the same Traffic Selectors are desired, the initiator will add the SA_RESOURCE_INFO notify payload to the Exchange negotiating the Child SA (eg IKE_AUTH or CREATE_CHILD_SA). If this initial Child SA will be tied to a specific resource, it MAY indicate this by including an identifier in the Notification Data. A responder that is willing to have multple Child SAs for the same Traffic Selectors will respond by also adding the SA_RESOURCE_INFO notify payload in which it MAY add a non-zero notify data payload. This text is a bit inconsistent with IKEv2 specification. In my reading the text implies that unless you exchange SA_RESOURCE_INFO, you cannot initiate multiple SAs with same selector, which is wrong - you can do it at any time if you follow RFC 7296. Only if you want to follow this draft (i.e. - associate each Child SA with some resource, and be able to limit their number with TS_MAX_QUEUE) you have to negotiate. I think that this subtle thing should be expressed more accurately. Changed to: If multiple Child SAs with the same Traffic Selectors that are bound to a single resource are desired, [...] 4. Section 3 These resource- specific Child SAs MUST be negotiated with identical Child SA properties that were negotiated for the initial Child SA. This includes cryptographic algorithms, Traffic Selectors, Mode (e.g. transport mode), compression usage, etc. However, each Child SA does have its own keying material that is individually derived according to the regular IKEv2 process. I think that MUST is over-restrictive if we talk about crypto algorithms. For crypto algorithms herhaps something along the lines: SHOULD be negotiated with the same crypto algorithms; if they differ, then they MUST provide identical level of protection. I don't agree. We are basically making "clones", so I see no reason why to make this more complicated by allowing things to be more different in various ways. The negotiation for the first child and second child should follow from the same configuration so it should really also end up returning the same crypto algorithms. Unless you would make choics based on trigger packet on specific resource, but that's something I am happy to not create another knob for. If others really feel similar to Valery, please speak out. We would also than need to make a clear list of all the knobs that MUST be the same and all the ones that SHOULD be the same. I'd rather not make that list :P (I agree that Mode and Traffic Selectors MUST be the same, not sure about compression). 5. Section 3 During the CREATE_CHILD_SA rekey for the Child SA, the SA_RESOURCE_INFO notification MAY be included, but regardless of whether or not it is included, the rekeyed Child SA MUST be bound to the same resource(s) as the Child SA that is being
Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance
On Wed, 15 Nov 2023, Yoav Nir wrote: Do you think it be better for each end to announce a maximum ahead of time? (At negotiation of the first child SA) I think so, but not completely sure. Suppose one peer is willing to go to 32 parallel SAs, while the other is going to stop at 8, because one has 32 cores and the other 8. So on the “big” gateway, all flows that fit the TS should be forwarded to one of 8 cores. If this was negotiated upfront, the big gateway can choose which 8. As it is, the first 8 cores that triggered the negotiation get SAs, while the rest have to forward after a short delay while trying and failing to negotiate an SA. Maybe it’s not an issue because SAs can be moved among cores. The draft mentions this possibility. We tried this approach but it runs into a lot of corner cases if implementations try to closely match a very low number. Instead, just let it run and treat the TS_MAX_QUEUE as a very high "sanity" found. Maybe 256 or 1024 or even 10k if you only worry about DDoS. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance
> On 14 Nov 2023, at 19:46, Michael Richardson wrote: > > > Yoav Nir wrote: >> - Although it is implied, it should be stated explicitly that >> TS_MAX_QUEUE does not mean no more child SAs with these TS ever. As >> some child SAs get deleted and perhaps not rekeyed if they’re idle, if >> traffic picks up again, new child SAs with these TS can be created >> until the peer again blocks you with a TS_MAX_QUEUE. > > Do you think it be better for each end to announce a maximum ahead of time? > (At negotiation of the first child SA) I think so, but not completely sure. Suppose one peer is willing to go to 32 parallel SAs, while the other is going to stop at 8, because one has 32 cores and the other 8. So on the “big” gateway, all flows that fit the TS should be forwarded to one of 8 cores. If this was negotiated upfront, the big gateway can choose which 8. As it is, the first 8 cores that triggered the negotiation get SAs, while the rest have to forward after a short delay while trying and failing to negotiate an SA. Maybe it’s not an issue because SAs can be moved among cores. The draft mentions this possibility. Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance
Yoav Nir wrote: > - Although it is implied, it should be stated explicitly that > TS_MAX_QUEUE does not mean no more child SAs with these TS ever. As > some child SAs get deleted and perhaps not rekeyed if they’re idle, if > traffic picks up again, new child SAs with these TS can be created > until the peer again blocks you with a TS_MAX_QUEUE. Do you think it be better for each end to announce a maximum ahead of time? (At negotiation of the first child SA) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance
Hi, I support publication of this draft. I'm glad authors took my points into consideration while preparing the latest version. I do have some comments though. 1. Section 1 IKEv2 [RFC7296] already allows installing multiple Child SAs with identical Traffic Selectors, but it offers no method to indicate that the additional Child SA is being requested for performance increase reasons and is restricted to some resource (queue or CPU). Without this indication, the peer might not accept multi Child SAs with identical Traffic Selectors and might delete one of the Child SAs it considered an unwanted duplicate. There is some inconsistency here. You first say that IKEv2 allows creating multiple identical Child SAs and then say that implementations would delete them as unwanted duplicates. Clearly these implementations violate RFC 7296, and we don't consider broken implementations, do we? :-) I suggest to remove the last sentence, or to add a clarification. 2. Section 2 There are a number of practical reasons why most Implementations have to limit a Child SA to only one specific hardware resource, but a key limitation is that sharing the crypto state, counters and sequence numbers between multiple CPUs is not feasible without a significant performance penalty. Shouldn't it be clarified, that the performance problems arise if you use an SA by several CPUs at the same time? I don't think there are problems if you use the SA by several CPUs at different time. Consider you have an SA with a traffic one packet per hour. Each time it is processed up by a different CPU, then the resulted state is stored in the shared memory. So, perhaps s/one specific hardware resource/one specific hardware resource at any given time 3. Section 3 If multiple Child SAs with the same Traffic Selectors are desired, the initiator will add the SA_RESOURCE_INFO notify payload to the Exchange negotiating the Child SA (eg IKE_AUTH or CREATE_CHILD_SA). If this initial Child SA will be tied to a specific resource, it MAY indicate this by including an identifier in the Notification Data. A responder that is willing to have multple Child SAs for the same Traffic Selectors will respond by also adding the SA_RESOURCE_INFO notify payload in which it MAY add a non-zero notify data payload. This text is a bit inconsistent with IKEv2 specification. In my reading the text implies that unless you exchange SA_RESOURCE_INFO, you cannot initiate multiple SAs with same selector, which is wrong - you can do it at any time if you follow RFC 7296. Only if you want to follow this draft (i.e. - associate each Child SA with some resource, and be able to limit their number with TS_MAX_QUEUE) you have to negotiate. I think that this subtle thing should be expressed more accurately. 4. Section 3 These resource- specific Child SAs MUST be negotiated with identical Child SA properties that were negotiated for the initial Child SA. This includes cryptographic algorithms, Traffic Selectors, Mode (e.g. transport mode), compression usage, etc. However, each Child SA does have its own keying material that is individually derived according to the regular IKEv2 process. I think that MUST is over-restrictive if we talk about crypto algorithms. For crypto algorithms herhaps something along the lines: SHOULD be negotiated with the same crypto algorithms; if they differ, then they MUST provide identical level of protection. (I agree that Mode and Traffic Selectors MUST be the same, not sure about compression). 5. Section 3 During the CREATE_CHILD_SA rekey for the Child SA, the SA_RESOURCE_INFO notification MAY be included, but regardless of whether or not it is included, the rekeyed Child SA MUST be bound to the same resource(s) as the Child SA that is being rekeyed. Isn't binding a local matter? Doesn't peer bother to what resource you bound your end of an SA? Then why is there this MUST? What happens if I bound new SA to a different CPU - peer never know this, so how it will check that you follow this MUST? I think that instead of this requirement there should be just a recommendation for implementers (with no BCP14 language). 6. Section 4 A simple distribution could be to install one additional Child SA on each CPU. An implementation MAY ensure that one Child SA can be used by all CPUs ... I believe it should be "can" instead of "MAY", since it is a local matter. 7. Section 4 When the number of queue or CPU resources are different between the peers, the peer with the least amount of resources MAY decide to not install a second outbound Child SA for the same resource as it will never use it to send traffic. Again, I think it should be "can" instead of "MAY", since it is a local matter. 8. Section 4 If per-CPU SADB_ACQUIRE messages are implemented (see Section 6), the Traffic Selector (TSi) entry containing the
Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance
> On 13 Nov 2023, at 12:31, Sahana Prasad wrote: > > Hello, > > I've read the draft and support its adoption. To clarify, the draft is already adopted since July 2021. The question now is whether it is ready to proceed to publication. > Specifically, we (at Red Hat) have use cases where customer to data center > links > see performance penalties for enabling IPsec on these > connections. We've been looking at how to fix this and this draft > seems to be a solution for our use case. Since I now realize now that it was not clear from my message, I agree. Yoav (with no hats) ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance
I support the draft to be moved forward. some nits: """ 2. Performance bottlenecks There are a number of practical reasons why most Implementations have ... """ """ As per RFC 7296 """ Should we move section 8 into the appendix instead of removing the section ? I am also interested in the performance benchmark if it is available. Yours, Daniel On Mon, Nov 13, 2023 at 5:32 AM Sahana Prasad wrote: > Hello, > > I've read the draft and support its adoption. > > Specifically, we (at Red Hat) have use cases where customer to data center > links > see performance penalties for enabling IPsec on these > connections. We've been looking at how to fix this and this draft > seems to be a solution for our use case. > > Thank you, > Regards, > Sahana Prasad > > On Sun, Nov 12, 2023 at 10:15 PM Yoav Nir wrote: > >> Hi. >> >> I’ve read the draft. Overall, it’s similar to a non-standardized solution >> we did at Check Point several years ago, so I agree that it is a solution >> that works. Of course, since there *are* a bunch of working >> implementations, that is not particularly insightful. >> >> With a lot of flows, it’s likely that in most situations the number of >> parallel SAs is going to be about the same as the number of “resources”. >> The text in section 4 does mention the issue of having peers with a >> different number of CPUs. In practice these can be very different. It’s not >> unheard of to have a center office with dozens of CPUs working with a >> branch office machine with one. The way this protocol seems to work is that >> the center office will attempt to create dozens of SAs, only to be stopped >> by the branch office which at some point will return the TS_MAX_QUEUE >> notification. I’m not a big fan of creating as many SAs as you can until >> the peer fails you, but the alternative would be to pre-negotiate the >> ts_max_queue value. >> >> A couple of editorial comments: >> - Although it is implied, it should be stated explicitly that >> TS_MAX_QUEUE does not mean no more child SAs with these TS ever. As some >> child SAs get deleted and perhaps not rekeyed if they’re idle, if traffic >> picks up again, new child SAs with these TS can be created until the peer >> again blocks you with a TS_MAX_QUEUE. >> - With a single SA pair per TS, implementations can expect that all >> packets in a flow (such as a TCP connection) will go through the same SA >> pair. This is especially important in implementations that are combined >> with firewalls. I think we need explicit text that says packets for any >> flow may come on any of the SAs from the logical group of child SAs. >> Perhaps: >> >> “implementations MUST NOT assume that all packets of a particular flow >> will be encrypted with a particular SA in the logical group of child SAs. >> ” >> >> Yoav >> >> >> >> On 25 Oct 2023, at 1:40, Tero Kivinen wrote: >> >> This will start three week working group laste call for >> draft-ietf-ipsecme-multi-sa-performance. The working group last call >> will end at 2023-11-15. >> >> Please review the document and send comments to the list if you think >> it is ready for publication. >> -- >> kivi...@iki.fi >> >> ___ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >> ___ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Ericsson ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance
Hello, I've read the draft and support its adoption. Specifically, we (at Red Hat) have use cases where customer to data center links see performance penalties for enabling IPsec on these connections. We've been looking at how to fix this and this draft seems to be a solution for our use case. Thank you, Regards, Sahana Prasad On Sun, Nov 12, 2023 at 10:15 PM Yoav Nir wrote: > Hi. > > I’ve read the draft. Overall, it’s similar to a non-standardized solution > we did at Check Point several years ago, so I agree that it is a solution > that works. Of course, since there *are* a bunch of working > implementations, that is not particularly insightful. > > With a lot of flows, it’s likely that in most situations the number of > parallel SAs is going to be about the same as the number of “resources”. > The text in section 4 does mention the issue of having peers with a > different number of CPUs. In practice these can be very different. It’s not > unheard of to have a center office with dozens of CPUs working with a > branch office machine with one. The way this protocol seems to work is that > the center office will attempt to create dozens of SAs, only to be stopped > by the branch office which at some point will return the TS_MAX_QUEUE > notification. I’m not a big fan of creating as many SAs as you can until > the peer fails you, but the alternative would be to pre-negotiate the > ts_max_queue value. > > A couple of editorial comments: > - Although it is implied, it should be stated explicitly that TS_MAX_QUEUE > does not mean no more child SAs with these TS ever. As some child SAs get > deleted and perhaps not rekeyed if they’re idle, if traffic picks up again, > new child SAs with these TS can be created until the peer again blocks you > with a TS_MAX_QUEUE. > - With a single SA pair per TS, implementations can expect that all > packets in a flow (such as a TCP connection) will go through the same SA > pair. This is especially important in implementations that are combined > with firewalls. I think we need explicit text that says packets for any > flow may come on any of the SAs from the logical group of child SAs. > Perhaps: > > “implementations MUST NOT assume that all packets of a particular flow > will be encrypted with a particular SA in the logical group of child SAs.” > > Yoav > > > > On 25 Oct 2023, at 1:40, Tero Kivinen wrote: > > This will start three week working group laste call for > draft-ietf-ipsecme-multi-sa-performance. The working group last call > will end at 2023-11-15. > > Please review the document and send comments to the list if you think > it is ready for publication. > -- > kivi...@iki.fi > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance
Hi. I’ve read the draft. Overall, it’s similar to a non-standardized solution we did at Check Point several years ago, so I agree that it is a solution that works. Of course, since there *are* a bunch of working implementations, that is not particularly insightful. With a lot of flows, it’s likely that in most situations the number of parallel SAs is going to be about the same as the number of “resources”. The text in section 4 does mention the issue of having peers with a different number of CPUs. In practice these can be very different. It’s not unheard of to have a center office with dozens of CPUs working with a branch office machine with one. The way this protocol seems to work is that the center office will attempt to create dozens of SAs, only to be stopped by the branch office which at some point will return the TS_MAX_QUEUE notification. I’m not a big fan of creating as many SAs as you can until the peer fails you, but the alternative would be to pre-negotiate the ts_max_queue value. A couple of editorial comments: - Although it is implied, it should be stated explicitly that TS_MAX_QUEUE does not mean no more child SAs with these TS ever. As some child SAs get deleted and perhaps not rekeyed if they’re idle, if traffic picks up again, new child SAs with these TS can be created until the peer again blocks you with a TS_MAX_QUEUE. - With a single SA pair per TS, implementations can expect that all packets in a flow (such as a TCP connection) will go through the same SA pair. This is especially important in implementations that are combined with firewalls. I think we need explicit text that says packets for any flow may come on any of the SAs from the logical group of child SAs. Perhaps: “implementations MUST NOT assume that all packets of a particular flow will be encrypted with a particular SA in the logical group of child SAs.” Yoav > On 25 Oct 2023, at 1:40, Tero Kivinen wrote: > > This will start three week working group laste call for > draft-ietf-ipsecme-multi-sa-performance. The working group last call > will end at 2023-11-15. > > Please review the document and send comments to the list if you think > it is ready for publication. > -- > kivi...@iki.fi > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance
I have read the draft. I think the draft could advance as it is. I have a few editorial comments, which authors may take with a grain of salt. On the implementation considerations: } This information } MAY be used by the peer to select the most optimal target CPU to } install the additional Child SA on. For example, if the trigger } packet was for a TCP destination to port 25 (SMTP), it might be able } to install the Child SA on the CPU that is also running the mail } server process. Trigger packet Traffic Selectors are documented in } [RFC7296] Section 2.9. It's not a bad example, but probably not very useful. I would say that many scalable gateways will use some kind of ECMP cache to direct flows of traffic to specific CPUs in order to keep packet re-orders to the minimum. The utility of that trigger packet is to be able to pull that flow out. section 3: } Upon installation, each resource-specific Child SA is associated with } an additional local selector, such as CPU or queue. These resource- } specific Child SAs MUST be negotiated with identical Child SA } properties that were negotiated for the initial Child SA. This } includes cryptographic algorithms, Traffic Selectors, Mode (e.g. } transport mode), compression usage, etc. However, each Child SA does Why is it a MUST that the new Child SAs need to use the same algorithm? It seems like that there could be situations where some CPUs are better at AES-GCM and others are better at ChaCha, and that would seem to be okay. Maybe SHOULD is enough? Is there a reason to reject a proposal because it didn't match the other SAs (but is otherwise within one's policy) > * Optional Payload Data. This value MAY be set to convey the local > identity of the resource. The value SHOULD be a unique identifier > and the peer SHOULD only use it for debugging purposes. If the presence of the payload is optional, and I always omit it, then it won't be unique, will it? Is that a problem? > And > bringing the deleted per-CPU Child SA up again immediately after > receiving the Delete Notify might cause an infinite loop between the > peers. I think this coud use an example. > Another issue Perhaps it's a new paragraph. > the first Child SA without ever activating any per-CPU Child SAs. It > is there for RECOMMENDED to implement per-CPU SADB_ACQUIRE messages. s/there for/therefore/ > intended CPUs is RECOMMENDED. An implementation MAY limit the number > of Child SAs only based on its resources - that is only limit these > based on regular denial of service protection. Although having too > many SAs may slow down per-packet SAD lookup. can an implementation that returns an TS_MAX_QUEUE at 13:05, then have more resources at 13:07? How long should one remember that one ran up against the maximum? > If this method is supported, >implementations must be careful to move both the inbound and outbound > SAs. what is the consequence if they don't do this? > For example, > using the CPU number itself as identier might give an attacker > knowledge which packets are handled by which CPU ID and it might > optimize a brute force attack against the system. An attacker that can see into your IKEv2 packets, can also do many other things. They are a peer. I think this is poor advice. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance
I've read the draft and spent the last 2 months testing/evaluating/debugging the linux xfrm implementation. I think the code is quite elegant and the results are very promising (line rate on 100G ENA nic) and thus support this draft. There is quite a bit of interest in my company (Aviatrix Systems) in seeing this work get adopted. Thanks, Daniel ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance
Obligatory: I have read the draft. I strongly support advancing this work to RFC status. We definitely have plans to use this with IP-TFS development both in linux kernel as well as in other projects such as VPP. Thanks, Chris. Tero Kivinen writes: This will start three week working group laste call for draft-ietf-ipsecme-multi-sa-performance. The working group last call will end at 2023-11-15. Please review the document and send comments to the list if you think it is ready for publication. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance
This will start three week working group laste call for draft-ietf-ipsecme-multi-sa-performance. The working group last call will end at 2023-11-15. Please review the document and send comments to the list if you think it is ready for publication. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
