Subject: [nmrg] Comments on draft-irtf-nmrg-ibn-concepts-definitions

From: "Rezaki, Ali (Nokia - DE/Munich)" <[email-masked]>
Date: Fri, 3 Jul 2020 07:48:59 +0000

Dear All,

I had the opportunity to review the Intent-Based Networking - Concepts and Definitions draft. Many thanks for providing it. I have the following general and security related comments please:

  1.  Would it be possible to include an example of an “intent” in the draft? Currently, it somehow looks quite abstract for an uninitiated reader. How would intents be different for different networks? As compared to policies, intents are to be more higher level and in this sense, if it approaches “networking principles” level, then, would most networks have similar intent?
  2.  It is stated that all devices and nodes in a network would interpret the intent themselves. Would this be scalable and secure? How do updates propagate in the network, etc? What happens if/when each node interprets the intent differently? I understand that there is the assurance functionality but still, this might create additional vulnerabilities perhaps? As an example, the challenges of DNS security or vulnerabilities in routing protocols and the difficulties in securing them.
  3.  What would be the relationship between IBN and PBNM: is there a hierarchy? How do we ensure that IBN and PLMN are in sync when they are present together?
  4.  Would the addition of a principle in section 5 on security/trustworthiness be helpful? I appreciate that the “Security considerations” section is quite extensively written. However, specifically emphasizing that there is a “trustworthiness” challenge might be helpful. Like in all learning systems this is a real concern as so much of control and visibility seems to be transferred to autonomic systems.
  5.  SSoT seems to be a single point of failure? IBN generally seems to be a distributed system but the SSoT looks like holding the core functionality and if cannot be distributed, some redundancy or other resilience mechanisms need to be built in.
  6.  Intent Assurance: it is natural to think of malicious intent as part of this topic but this is only mentioned in the security considerations section. Like the suggested principle above, it might be helpful to provide links for it from “intent assurance” procedures as well.
  7.  Closed loop maintenance: what are the assurance functions available to monitor/mitigate the completely automated “inner” control loop? There better be some verification points or “anchors” for maintenance and troubleshooting. This could be a general comment that applies to most of the system. Transparency is another principle, that could perhaps be added.
  8.  My (perhaps limited) understanding of the security considerations section is that it somehow outlines what the potential threats to the mechanisms outlined in the draft are and how related potential vulnerabilities are addressed in the current draft and what would be the remaining residual risks. The prior design content of the draft can include separate sub-sections on security mechanisms.
  9.  The third facet described in the security considerations section - expressing security as an intent: it would perhaps be helpful to specify this a bit more as to what level of abstraction/detail is involved here. Security professionals are generally not comfortable with abstract or non-deterministic concepts, although risk management is exactly that way. Regardless, how abstract or high level IBN security intents would be and how would they need to be interpreted to create a system wide assurance?
  10. Insider threats in general cannot be mitigated very successfully and are usually left out. Here, also, a trust model is needed first. Who/what is trusted and who/what needs to be checked/monitored?

I can reiterate that the “security considerations” section in the draft seems to cover everything related to security and I think that some of it can be transferred as main content sections. As a technology that is having major control and configuration reach network-wide, also using “learning” mechanisms, I think IBN would benefit from expressing security/trustworthiness topics more centre-stage.

Please take these as comments coming from someone not exposed to the IBN topic in very much detail. I hope they might provide an additional perspective.

Many thanks again for this opportunity to review.

Stay healthy!

Best regards,

Ali