[IPsec] Robert Wilton's No Objection on draft-ietf-ipsecme-mib-iptfs-06: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-ipsecme-mib-iptfs-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-mib-iptfs/ -- COMMENT: -- Hi, Thanks for this document. Please can you add an RFC editor's note to ensure that the MIB Module and MIB tree are suitably updated once IANA has assigned a code point for the iptfsMIB. I support Eric's comment that Guage32 (or possibly even CountedBasedGauge64 defined in RFC 2856) may be a better choice than Counter64 for the l2FixedRate and l3FixedRate. However, I also appreciate that there is probably also a strong desire to keep the MIB entirely consistent with the YANG. I noted that the IANA considerations section is requesting an OID code point for both the iptfs and ipsec MIBs, but it wasn't clear to me why ipsec was being registered here, since the isn't any ipsec MIB being defined in this document. Is this registration left over from an earlier draft, or does it serve some other purpose? Regards, Rob ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Discussion of draft-pwouters-ipsecme-multi-sa-performance
Hi Steffen, > > > Valery Smyslov wrote: > > > > My main problem with the draft is the concept of "Fallback SA". > > > This SA > > > > is treated specially in the draft, which I don't think is > > > > necessary. For example, it must always be up so that the outgoing > > > > packet can always be sent in case per-CPU SA does not exist. Why > > > other > > > > existing per-CPU SAs cannot be used for this purpose? > > > > > > Because the point of the per-CPU CAs is that they are local to the CPU > > > and so > > > they do not require locks to acces/update. > > > > True. > > > > > I could guess that the fallback SA *does* require locks. > > > > It also seems to me. So I see no difference if the packet > > can be re-steered to a different CPU, in any case we'll have > > performance penalty. > > The fallback SA needs locking, as it can be used from any cpu. > But with the current approch, this is the only one that needs > locking. Then my next question is - how the sending side decides whether to one of use per-CPU SAs or the fallback SA? My guess that the packet is handled by some kernel thread (i.e. by some CPU), so once this CPU figures out that it doesn't have an SA - I assume it uses the fallback SA then. Is it right? If so, then why it cannot hand over the packet to the CPU that for sure has the needed SA (this CPU can be indicated in the stub SA entry)? In both cases some locking is required - does the latter case require much more locking? > If you try to re-steer packets to a different cpu, you > need to do lookups in the SAD from remote cpus to find a > cpu that has a SA that can process the packet, what in turn > would require to lock per percpu databases too. I presume the packet is handed over to a particular CPU that does have the SA, so only one per-CPU database is looked ip. [snipped] > > > The read-only copy of the SPD can be replicated per-CPU, with the counters > > > being updates by RCU. I don't understand your stub SA use. > > > > Because we need to indicate somewhere that SA with identical traffic > > selectors > > exists for another CPU, but not for this one. This is dynamic information > > and it cannot reside in SPD. > > We use the fallback SA as a 'stub one'. The difference is that we > look it up in the global SAD and actually use it because it has > key material negotiated. Another issue that is not clear from the draft - how per-CPU SAs are created. Consider the situation when an outgoing packet is handled by a CPU and there is no per-CPU Sa to handle it. Then, I assume, the fallback SA is used. My question - in this case does this CPU additionally requests IKE to create a per-CPU SA for it? If so, then what happens if the other side has indicated that no more per-CPU SAs is allowed - is it saved somewhere, so that future outgoing packets handled by CPUs with no per-CPU SA, don't trigger requests to create it anymore? > > > > This way the new SAs are created dynamically and treated equally - > > > they > > > > all live their own life - are re-keyed or even deleted if they are > > > idle > > > > for a long time. > > > > > > If there are SAs which are being used more than others, than there is > > > something wrong. > > > > My point is that it doesn't matter how they are used - they > > live their own life. Generally with a good enough randomizing > > algorithm all of them should be used roughly equally. > > We don't require a fallback SA in the draft, we just recommend to have > one. So in that sense, once created, all SAs live their own live. Hmm, my impression from reading the draft is that it is not so: Section 3: When negotiating CPU specific Child SAs, the first SA negotiated either in an IKE_AUTH exchange or CREATE_CHILD_SA is called Fallback SA. This Fallback Child SA (or its rekeyed successors) MUST remain active for the lifetime of the IPsec session to ensure that there is always a Child SA that can be selected to send traffic over, in case a per-resource Child SA is not available. The Fallback SA MUST NOT be deleted while any per-resource Child SAs are still present. Section 4: The Fallback Child SA MUST NOT be deleted when idle, as it is likely to be idle if enough per-CPU Child SAs are installed. I think that these BCP14 requirements make the fallback SA very special. Regards, Valery. > Steffen ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Discussion of draft-pwouters-ipsecme-multi-sa-performance
Hi Steffen, [snipped] > > My main problem with the draft is the concept of "Fallback SA". This SA is > > treated specially in the draft, > > which I don't think is necessary. For example, it must always be up so that > > the outgoing packet can > > always be sent in case per-CPU SA does not exist. Why other existing > > per-CPU SAs cannot be used > > for this purpose? > > Argued about that in my other mail. I replied to it with my considerations. > > Another thing that I think is unnecessary is the CPU_QUEUES notify. > > Apart from indicating that the SA is a Fallback SA (which I think is not > > needed), I cannot > > see any usefulness of this notify. In particular - it contains the minimum > > number of parallel > > SAs peer wants to have - so for the receiving side its information makes no > > difference. > > For example, I want 3, you wants 5, we end up with 5 (as the bigger), but > > in fact I can always send > > TS_MAX_QUEUE after creating 3. No difference what values are indicated, > > they can be arbitrary. > > Sure, you can do that. The intention behind this was to decide if both > peers can benefit from doing a pcpu SA setup. Consider a setup where > one peer has 1000 cpus and the other peer has just 2. If the one with > 1000 cpus tries to install a SA for each cpu, the other ends SAD lookup > becomes very inefficient. On the other hand, each peer needs to be able > to install at least as many SAs as it has cpus. Otherwise some cpus > have to use always the fallback SA or need to re-steer flows to > other cpus. That is inefficient too, so there should be a way to > detect if the difference is too big to use pcpu SAs efficent for > both sides. So if the other end asks for a too big CPU_QUEUES > number you can just say, no let's just use one SA for all the traffic. I still don't understand the idea. For example, there is an IPsec implementation with say 10 CPUs. Does it make any difference for this implementation If it receives CPU_QUEUES with 100 or with 1000? It seems to me that in both cases it will follow its own local policy for limiting the number of per-CPU SAs, most probably capping it to 10. Or do you want to say that the logic would be: well my peer has 1000 CPUs, it's not good for me to have more than 10, but let's be friendly and install 100, so that both of us are suffer... I don't think this logic is credible in real life, but even in this case there is already a mechanism that allows to limit the number of per-CPU SAs - it is the TS_MAX_QUEUE notify. So why we need CPU_QUEUES? > > I'm also not convinced that CPU_QUEUE_INFO is really needed, it mostly > > exists > > for debugging purposes (again if we get rid of Fallback SA). And I don't > > think we need > > a new error notify TS_MAX_QUEUE, I believe TS_UNACCEPTABLE can be used > > instead. > > Ok. > > > So, in my understanding, the architecture for multi-SA protocol could be as > > follows. > > An IPsec endpoint supporting this feature has several CPUs (or several > > cores, but let's call them CPUs). > > There is some mechanism that dispatches outgoing packets to different CPUs > > in some fashion > > (randomly or with round-robin algorithm or using some affinity). There also > > is some mechanism that > > deterministically dispatches incoming ESP packets to CPUs based on some > > information > > from the packets, most probably from the content of SPI. > > > > With these kernel features in mind the following IPsec architecture could > > be implied. > > The SPD is global for all CPUs, while SAD is split into several copies, so > > that each CPU has > > its own SAD. We also need to introduce a special entry in the SAD - "stub > > SA", that > > only constitutes of a selector and has no associated SA. > > > > When there is an outgoing packet on the initiator, then it is handled by > > one of CPUs. > > This CPU checks its own SAD and founds no SA that matches packet selector, > > so > > it checks the SPD and finds a rule saying that this packets with this > > selector > > must be protected with ESP. Then this CPU requests IKE for creating the ESP > > SA. > > IKE performs the needed actions and as a result it creates a pair of ESP > > SAs. > > This is all usual actions with no deviation from any ordinary IPsec > > implementation. > > > > The difference is that then IKE installs this pair of SAs only to the SAD > > for that very > > CPU that requested its creation. Note, that an SPI for the incoming ESP SA > > should be selected in such a way, that the mechanism steering incoming > > packets > > to an appropriate CPU must correctly steer this SPI to the CPU that this SA > > is installed for. > > All other SADs (for the rest CPUs) are populated with a stub SA entry, > > having the > > same selector and a pointer to the CPU that have real SA installed. > > That would require a write to all remote pcpu SADs, so the percpu SADs > can't be lockless. Yes, but these evens (creating new SAs) are relat
[IPsec] I-D Action: draft-ietf-ipsecme-mib-iptfs-07.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Definitions of Managed Objects for IP Traffic Flow Security Authors : Don Fedyk Eric Kinzie Filename: draft-ietf-ipsecme-mib-iptfs-07.txt Pages : 23 Date: 2022-10-17 Abstract: This document describes managed objects for the management of IP Traffic Flow Security additions to IKEv2 and IPsec. This document provides a read only version of the objects defined in the YANG module for the same purpose. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-mib-iptfs/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-ipsecme-mib-iptfs-07.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-mib-iptfs-07 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-mib-iptfs-06: (with DISCUSS and COMMENT)
Hi Eric Thanks for you Review. We have posted an updated draft 07 to address your comments. Note I Revalidated the MIB with the changes, but I realized I didn’t update the tree in the draft. So, I have one pending change, but I will wait and see if we satisfied your points. See [Don] Below. Thanks Don -Original Message- From: Éric Vyncke via Datatracker Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-mib-iptfs-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-mib-iptfs/ -- DISCUSS: -- # Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-mib-iptfs-06 CC @evyncke Thank you for the work put into this document (even if I am balloting a DISCUSS); Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Tero Kivinen for the shepherd's detailed write-up including the WG consensus *but* it lacks the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ### Inconsistent intended status & use of experimental code point This document is standard track, but the OID used in section 4.1 is 'experimental' and in section 4.2 `experimental 500` per https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml. Please request IANA to assign an OID from the 1.3.6.1.2.1 tree. [Don] This was a holdover from the initial draft. We have updated to be consistent with the IANA requests and your comment. BTW Thank you for helping us clarify where this should be placed. -- COMMENT: -- ## COMMENTS ### Section 1 ``` Note an IETF MIB model for IPsec was never standardized however the structures here could be adapted to existing MIB implementations. ``` [Don] we updated to: adapted to existing proprietary MIB implementations where SNMP is used to manage networks. Perhaps clarify "existing MIB implementations" ? I guess this is about proprietary IPsec MIBs, but clarification will be welcome. ### Section 4.2 Should the construct with `` be used to allow for easy file extraction ? [Don] OK Roman had requested this comment and I looked for MIB examples and found none. But as I updated the YANG, I found the sourcecode tag and used that for a mib and nothing seem to complain. We may be the only MIB that ever used this though. `mailto:ekinzie.labn.net` is probably wrong ;-) [Don] Fixed. `l2FixedRate`and `l3FixedRate` have 'counter64' type, RFC 2578 section 7.1.10 defines this type as monotically increasing. I understand that there are no interger64 in RFC 2578 but why not using a different unit than 'bps' for those two items ? [Don] We updated this CounterBasedGauge64 - Does this satisfy your point? SNMP has a richer set of types. ### Section 5 The IANA section should probably follow more closely RFC 8126, notably specifying the right registry (e.g., "SMI Network Management MGMT Codes Internet-standard MIB") [Don] Thanks we updated this an noted. ### Section 8.1 Unsure whether I-D.ietf-ipsecme-yang-iptfs (and perhaps I-D.ietf-ipsecme-iptfs) is a normative reference (i.e., I can implement this I-D MIB without accessing the YANG module). [Don] We moved the YANG to informative. We left the IP-TFS core draft as normative since it is the source for the attributes. ## NITS ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-mib-iptfs-06: (with DISCUSS and COMMENT)
Don You were faster than the light ;-) Indeed, the changes are ok for me and, more important, I do believe that they have improved the document. I also noticed that the tree is not updated, but I will trust you (and your AD) on this point. I will clear my DISCUSS shortly. Thank you for your reply and your work Regards -éric On 17/10/2022, 19:27, "Don Fedyk" wrote: Hi Eric Thanks for you Review. We have posted an updated draft 07 to address your comments. Note I Revalidated the MIB with the changes, but I realized I didn’t update the tree in the draft. So, I have one pending change, but I will wait and see if we satisfied your points. See [Don] Below. Thanks Don -Original Message- From: Éric Vyncke via Datatracker Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-mib-iptfs-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-mib-iptfs/ -- DISCUSS: -- # Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-mib-iptfs-06 CC @evyncke Thank you for the work put into this document (even if I am balloting a DISCUSS); Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Tero Kivinen for the shepherd's detailed write-up including the WG consensus *but* it lacks the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ### Inconsistent intended status & use of experimental code point This document is standard track, but the OID used in section 4.1 is 'experimental' and in section 4.2 `experimental 500` per https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml. Please request IANA to assign an OID from the 1.3.6.1.2.1 tree. [Don] This was a holdover from the initial draft. We have updated to be consistent with the IANA requests and your comment. BTW Thank you for helping us clarify where this should be placed. -- COMMENT: -- ## COMMENTS ### Section 1 ``` Note an IETF MIB model for IPsec was never standardized however the structures here could be adapted to existing MIB implementations. ``` [Don] we updated to: adapted to existing proprietary MIB implementations where SNMP is used to manage networks. Perhaps clarify "existing MIB implementations" ? I guess this is about proprietary IPsec MIBs, but clarification will be welcome. ### Section 4.2 Should the construct with `` be used to allow for easy file extraction ? [Don] OK Roman had requested this comment and I looked for MIB examples and found none. But as I updated the YANG, I found the sourcecode tag and used that for a mib and nothing seem to complain. We may be the only MIB that ever used this though. `mailto:ekinzie.labn.net` is probably wrong ;-) [Don] Fixed. `l2FixedRate`and `l3FixedRate` have 'counter64' type, RFC 2578 section 7.1.10 defines this type as monotically increasing. I understand that there are no interger64 in RFC 2578 but why not using a different unit than 'bps' for those two items ? [Don] We updated this CounterBasedGauge64 - Does this satisfy your point? SNMP has a richer set of types. ### Section 5 The IANA section should probably follow more closely RFC 8126, notably specifying the right registry (e.g., "SMI Network Management MGMT Codes Internet-standard MIB") [Don] Thanks we updated this an noted. ### Section 8.1 Unsure whether I-D.ietf-ipsecme-yang-iptfs (and perhaps I-D.ietf-ipsecme-iptfs) is a normative reference (i.e., I can implement this I-D MIB without accessing the YANG module). [Don] We moved the YANG to informative. We left the IP-TFS core draft as normative since it is the source for the attributes. ## NITS ## Notes This review is in the ["IETF Comments" Mark
[IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-mib-iptfs-07: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-mib-iptfs-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-mib-iptfs/ -- COMMENT: -- Thank you, Don, for quickly addressing my DISCUSS and COMMENT points from my ballot. I sincerely hope that this discussion has improved the document. Please do not forget to also update the tree with the right OID prefix ;-) but I am trusting you and the AD, Roman. For archive: the previous DISCUSS ballot is at https://mailarchive.ietf.org/arch/msg/ipsec/sbb3MSPy8XwkHPIZCNt9ZRCd6BQ/ Regards -éric ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] I-D Action: draft-ietf-ipsecme-mib-iptfs-08.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Definitions of Managed Objects for IP Traffic Flow Security Authors : Don Fedyk Eric Kinzie Filename: draft-ietf-ipsecme-mib-iptfs-08.txt Pages : 23 Date: 2022-10-17 Abstract: This document describes managed objects for the management of IP Traffic Flow Security additions to IKEv2 and IPsec. This document provides a read only version of the objects defined in the YANG module for the same purpose. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-mib-iptfs/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-ipsecme-mib-iptfs-08.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-mib-iptfs-08 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Discussion of draft-pwouters-ipsecme-multi-sa-performance
On Mon, 17 Oct 2022, Valery Smyslov wrote: [leaving cache/linux implementation details to Steffen to answer] Another issue that is not clear from the draft - how per-CPU SAs are created. Consider the situation when an outgoing packet is handled by a CPU and there is no per-CPU Sa to handle it. Then, I assume, the fallback SA is used. Yes. My question - in this case does this CPU additionally requests IKE to create a per-CPU SA for it? Yes. In linux language, it would a per-CPU ACQUIRE to userland. If so, then what happens if the other side has indicated that no more per-CPU SAs is allowed - is it saved somewhere, so that future outgoing packets handled by CPUs with no per-CPU SA, don't trigger requests to create it anymore? I think this is implementation specific. You could install an temporary rule into the SPD that would give the fallback SA more priority than the per-CPU policy installed, so it wouldn't generate ACQUIRES for a while. Perhaps userland could also decide to terminate another per-CPU SA that is idle. Although I think the advised policy is stated to install at least one per-CPU SA per CPU (and allow a few more to catch any race conditions and rekeys). Clearly, if for part of the connection, you are using the fallback SA, you are running at suboptimal speed which is not a situation you should remain in. We don't require a fallback SA in the draft, we just recommend to have one. So in that sense, once created, all SAs live their own live. Hmm, my impression from reading the draft is that it is not so: Section 3: When negotiating CPU specific Child SAs, the first SA negotiated either in an IKE_AUTH exchange or CREATE_CHILD_SA is called Fallback SA. Indeed. The idea is that no matter what, you can encrypt the packets and send them, even if at sub-optimal speeds. We don't want packets to have to wait another RTT for the per-CPU SA to establish. That would cause a lot of issues (slow TCP retransmits, UDP application retransmits, etc). Once the first SA is up, you have a working IPsec tunnel and no more packets should be dropped or wait for SA's to establish. The Fallback Child SA MUST NOT be deleted when idle, as it is likely to be idle if enough per-CPU Child SAs are installed. I think that these BCP14 requirements make the fallback SA very special. Yes it does. It ensures there is a fully working (albeit slow) IPsec connection. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] John Scudder's No Objection on draft-ietf-ipsecme-mib-iptfs-08: (with COMMENT)
John Scudder has entered the following ballot position for draft-ietf-ipsecme-mib-iptfs-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-mib-iptfs/ -- COMMENT: -- # Routing AD comments for draft-ietf-ipsecme-mib-iptfs-08 ## COMMENTS ### Section 4.2 You have "TFS bit rate may be specified at layer 2 wire rate" and "TFS bit rate may be specified at layer 3 packet rate". Shouldn't that be "as", not "at"? I did go looking for insight in ipsecme-yang but it just made me think that document has the same (looks to me like a) bug. ### Section 6 I'm a little mystified why "For the implications regarding write configuration" considering this is a read-only MIB? (Which the very next paragraph goes on to say.) The same applies a few paragraphs down where you talk about "who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module" -- isn't it really just who can GET (read) the objects? And the same for the "Further" bullet point. ## NITS - s/paccket/packet/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Discussion of draft-pwouters-ipsecme-multi-sa-performance
I think that the point is that even if there are n CPUs, that a sensibly designed system might well have n+1 SAs active. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] John Scudder's No Objection on draft-ietf-ipsecme-mib-iptfs-08: (with COMMENT)
Hi John Please see [Don] inline: Thanks Don -Original Message- From: John Scudder via Datatracker John Scudder has entered the following ballot position for draft-ietf-ipsecme-mib-iptfs-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-mib-iptfs/ -- COMMENT: -- # Routing AD comments for draft-ietf-ipsecme-mib-iptfs-08 ## COMMENTS ### Section 4.2 You have "TFS bit rate may be specified at layer 2 wire rate" and "TFS bit rate may be specified at layer 3 packet rate". Shouldn't that be "as", not "at"? I did go looking for insight in ipsecme-yang but it just made me think that document has the same (looks to me like a) bug. [Don] Yes "as" is better. I will make a note for both docs. ### Section 6 I'm a little mystified why "For the implications regarding write configuration" considering this is a read-only MIB? (Which the very next paragraph goes on to say.) The same applies a few paragraphs down where you talk about "who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module" -- isn't it really just who can GET (read) the objects? And the same for the "Further" bullet point. [Don] We have specified YANG for full control write and read and SNMP MIB in this document for read only viewing of the MIB for backwards compatibility. The SNMP versions paragraph is a warning about using SNMP version that are vulnerable. The text was added as an overall security recommendation, and we did not scope that to read only for this MIB because is a general SNMP security comment. Is that explanation OK or would you like to see a change? ## NITS - s/paccket/packet/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] John Scudder's No Objection on draft-ietf-ipsecme-mib-iptfs-08: (with COMMENT)
Hi Don, If I understand you right, the answer on the security section amounts to “it’s just the standard boilerplate, John”. ;-) Which is fine — I was really more curious than anything else, there’s nothing wrong about the text in question, it just seems superfluous in this context. I’m fine if you want to keep it as written. Thanks for the quick reply, —John > On Oct 17, 2022, at 4:44 PM, Don Fedyk wrote: > > Hi John > > Please see [Don] inline: > > Thanks > Don > > -Original Message- > From: John Scudder via Datatracker > > > John Scudder has entered the following ballot position for > draft-ietf-ipsecme-mib-iptfs-08: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!GWDkwYgWBDmuOyF7fu0N7_eVqGssdVMCFEWzoWnh6CvVm7br9S5McKqG16UimDnm5wakihg7EgM$ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-ipsecme-mib-iptfs/__;!!NEt6yMaO-gk!GWDkwYgWBDmuOyF7fu0N7_eVqGssdVMCFEWzoWnh6CvVm7br9S5McKqG16UimDnm5wak1jfSRXA$ > > > > -- > COMMENT: > -- > > # Routing AD comments for draft-ietf-ipsecme-mib-iptfs-08 > > ## COMMENTS > > ### Section 4.2 > > You have "TFS bit rate may be specified at layer 2 wire rate" and "TFS bit > rate > may be specified at layer 3 packet rate". Shouldn't that be "as", not "at"? I > did go looking for insight in ipsecme-yang but it just made me think that > document has the same (looks to me like a) bug. > > [Don] Yes "as" is better. I will make a note for both docs. > > ### Section 6 > > I'm a little mystified why "For the implications regarding write > configuration" > considering this is a read-only MIB? (Which the very next paragraph goes on to > say.) The same applies a few paragraphs down where you talk about "who on the > secure network is allowed to access and GET/SET (read/change/create/delete) > the > objects in this MIB module" -- isn't it really just who can GET (read) the > objects? And the same for the "Further" bullet point. > > [Don] We have specified YANG for full control write and read and SNMP MIB in > this document for read only viewing of the MIB for backwards compatibility. > The SNMP versions paragraph is a warning about using SNMP version that are > vulnerable. The text was added as an overall security recommendation, and we > did not scope that to read only for this MIB because is a general SNMP > security comment. > > Is that explanation OK or would you like to see a change? > > > > > > > ## NITS > > - s/paccket/packet/ > > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Discussion of draft-pwouters-ipsecme-multi-sa-performance
On Mon, 17 Oct 2022, Valery Smyslov wrote: implementation with say 10 CPUs. Does it make any difference for this implementation If it receives CPU_QUEUES with 100 or with 1000? It seems to me that in both cases it will follow its own local policy for limiting the number of per-CPU SAs, most probably capping it to 10. That would be a mistake. You always want to allow a few more than the CPUs you have. The maximum is mostly to protect against DoS attacks. If you only have 10 CPUs, but the other end has 50, there shouldn't be much issue to install 50 SA's. Not sure if we said so in the draft, but you could even omit installing 40 of the outgoing SA's since you would never be expected to use them anyway. but you have to install all 50 incoming ones because the peer might use them. Or do you want to say that the logic would be: well my peer has 1000 CPUs, it's not good for me to have more than 10, but let's be friendly and install 100, so that both of us are suffer... At that point, it really also matters what the differences are between the CPUs. An embedded device with 4 cpus at 800mhz vs a mega supercomputer with 250 5ghz cpus. Already, counting CPUs is an approximation. Already, the application needs proper threading to use multiple CPUs without a single CPU bottleneck at the application layer. There might very well be situations where multi-sa doesn't really help you at all. But the simple use case is clear. I have a database cluster of 10 nodes talking to eachother with lots of CPUs and most are idle because I have one fully loaded CPU because my SA is bound to one CPU only. I don't think this logic is credible in real life, but even in this case there is already a mechanism that allows to limit the number of per-CPU SAs - it is the TS_MAX_QUEUE notify. So why we need CPU_QUEUES? TS_MAX_QUEUE is conveying an irrecoverable error condition. It should never happen. Where as CPU_QUEUES tells you how many per-CPU child SAs you can do. This is meant to reduce the number of in-flight CREATE_CHILD_SA's that will never become successful. I'm also not convinced that CPU_QUEUE_INFO is really needed, it mostly exists for debugging purposes (again if we get rid of Fallback SA). And I don't think we need a new error notify TS_MAX_QUEUE, I believe TS_UNACCEPTABLE can be used instead. We did it to distinquish between "too many of the same child sa" versus other errors in cases of multiple subnets / child SAs under the same IKE peer. Rethinking it, I am no longer able to reproduce why we think it was required :) there is no SA, this CPU requests IKE to create one for it. Meanwhile, the packet triggered this action can be 1) dropped 2) retained waiting for the SA to be ready or 3) re-steered to the CPU that already has an appropriate SA (it is indicated in the stub entry). On a preemptive system, the scheduler might migrate applications from one cpu to another from time to time. So 1 and 2 are IMO not appropriate as the application would stuck until a SA is created. 3 has its own problems as discussed in the other mail. OK, but also see my considerations there. The idea of the fallback SA is that you always have at least one child SA guaranteed to be up that can encrypt and send a packet. It can be installed to not be per-CPU. It's a guarantee that you will never need to wait (and cache?) 1 RTT's time worth of packets, which can be a lot of packets. You don't want dynamic resteering. Just have the fallback SA "be ready" in case there is no per-cpu SA. I think it depends. I'd like to see optimization efforts to influence the protocol as less as possible. Ideally this should be local matter for implementations. This would allow them to interoperate with unsupporting implementations (and even to benefit from multi-SAs even in these situations). Those that don't support this don't see notifies ? Or do you mean to somehow install multiple SA's for the same thing on "unsupported" systems? The problem currently is that when an identical child SA is successfully negotiated, implementations differ on what they do. Some allow this, some delete the older one. The goal of this draft is to make the desire for multple idential child SAs very explicit. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
