> On 17 Jul 2018, at 11:38, Rafa Marin-Lopez <r...@um.es> wrote:
<snip/> > Regarding the question about smart objects, I do not understand why a > constrained device cannot be a flow-based NSF. > I don’t think IOT devices are going to be NSFs. There is no hard definition for what a smart object is, but some common features are: - low power - intermittent operation - (relatively) weak in terms of CPU / memory / network bandwidth. Often this is measured in tens of kilobytes of memory and 100/250 kbps. - interacts with the real world - has sensors and/or actuators So none of this says NSF to me, especially the bandwidth. Which is why I believe that any device that is actually used as an NSF implementing IPsec is also likely to have enough power to run IKE. > Regarding case 2. It follows a SDN model: control plane and data plane. Data > plane the IPsec stack is the data plane, which deals with flows; control > plane is implemented in the SDN controller. NSF are simpler. One of the key > points here is that key material is seen by the SDN controller (which, we > should not forget, it is a trusted entity). In this sense, for example, > draft-carrel-ipsecme-controller-ike-00 proposes the usage of DH > public/private keys trying to avoid this. Other options could be also > considered. It is true that the SDN controller is a trusted entity. We still prefer to limit the attack surface by not giving it access to traffic keys. There is no doubt that a malicious controller can make the NSFs tunnel all traffic through a pervasive monitoring server. We have to trust it not to do that. What we can prevent is having it leak the traffic keys through printing them to logs, crashing and storing them in core files, swapping them from memory to disk and all the other ways that applications leak sensitive information. That’s just not good key hygiene. That said, a simpler NSF is an NSF that needs less maintenance, less software updates, less angst over random-number generators that turn out to be not random enough. It’s possible that there is a use case for your case #2 or draft-carrel’s modification. It would be interesting if someone has market data about whether people would like to deploy such configurations. Unfortunately, the slot this work has in I2NSF is not long enough to hash this out. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
