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 [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
