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

From: Alexander Clemm <[email-masked]>
Date: Thu, 3 Sep 2020 18:23:57 +0000

Dear Ali,
Please find my responses inline, <ALEX>.
Apologies for the late reply.
Best
--- Alex

From: nmrg <[email-masked]> On Behalf Of Rezaki, Ali (Nokia - DE/Munich)
Sent: Friday, July 3, 2020 12:49 AM
To: [email-masked]
Subject: [nmrg] Comments on draft-irtf-nmrg-ibn-concepts-definitions

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?

<ALEX> Thank you for the suggestion.  We don’t want to get into intent languages or such in the draft, but I agree that having some example will be useful and we plan to incorporate one in the next revision that we will post shortly.
</ALEX>

  1.  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.

<ALEX> Couple of things here.  For one, we don’t actually make a statement that every node would need to interpret intent.  There will be different ways to implement the functions in the Intent-Based System space (Figure 1).  They could certainly be distributed and would not necessarily be centralized, but at least at the conceptual  stage does not preclude nor mandate a particular way of implementation.  Regarding scalability and security of an architecture in which intent is interpreted within the network by devices that have a decentralized/distributed way of fulfilling and assuring the intent:  I would in fact expect that such solutions, if done right, would be very scalable as they do not introduce a single system as bottleneck.  The real question in such systems would be time until convergence, but as specified in section 5 (Principles), such convergence would not necessarily need to be instantaneous (“One-touch but not one-shot”).  Clearly there are interesting questions to address to ensure not just that intent is interpreted consistently (I don’t think this will be an issue, frankly; of course it depends on proper functions to recognize/translate/refine intent which constitutes a research problem in itself).  Just as important will be the question how independent systems can jointly act in coordinated fashion so that intent is achieved.  However, any of this is more of a question of research questions that can be articulated in conjunction with IBN, not so much a question of the concepts themselves.  Unless we want to decide to include a log of possible research questions in the draft, my feeling is this doesn’t belong here.  Regarding security, these issues and considerations are elaborated on in section 10; do you think anything is missing there that should be added?
</ALEX>

  1.  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?

<ALEX>The relationship is addressed in section 4.2.2.  I don’t think there is a hierarchy, but IBN may ultimately obviate the need for PBNM.  Is there room for both together in the same solution?  Sure; for example, I could see an IBN configure/establish policy rules as part of its configuration/provisioning actions being taken.  The policies in a PBNM need to come from somewhere; it is conceivable that intent is ultimately translated into policies.
</ALEX>

  1.  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.

<ALEX> What would you articulate as such principle?  It is very clearly an important consideration; I am not quite sure what we would put as a defining principle (not just a goal, which would also include other things like scalability).  I’ll need to think a bit more on this; I am not opposed but at the moment I am not sure what one would put there; perhaps this is an area where also others could chime in.
</ALEX>

  1.  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.

<ALEX> Well, conceptually there should be a single source of truth.  We would not want to have a network needing to deal with contradictory sources of intent and bear responsibility for negotiating between them.  We can make it clear that an SSoT implementation may be distributed, redundant etc.; will phrase accordingly.
</ALEX>

  1.  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.

<ALEX> Not sure what you are suggesting here?  Intent assurance simply refers to ensuring that intent is being followed.  It does not question or second-guess the intent itself, although clearly doublechecking etc would be part of the function that recognizes intent from interactions with the user.  As mentioned in the draft, those functions can involve unconventional human-machine interactions, in which a human will not simply give simple  commands, but which may involve a human-machine dialog to provide  clarifications, which might include such doublechecking.
 </ALEX>

  1.  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.

<ALEX> We should probably expand a little on the explanation of the loops and the individual functions in our next revision.  To your question, the loop is guided by the intent, observing the behavior of the network and taking actions as necessary to ensure the desired outcomes are achieved.  The intent assurance functions are listed in section 6.2.  With “transparency” you probably refer to explainability of actions.  In as far as intent is achieved by learning functions, explanations of particular actions taken involves many open questions for research.  As mentioned, expanding on research questions is currently not within the scope of this particular draft; probably this should be addressed by a separate effort.
</ALEX>

  1.  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.

<ALEX> I am not sure what you are suggesting here – break the security considerations section in to subsections?  Currently we discuss three different facets, each in a separate paragraph.  I think at this point introducing subsections would be a bit overkill (since they would only contain a paragraph each, and the logical structure I think is clear as is), but we will keep the suggestion in mind in case the section expands and grows in length.
</ALEX>

  1.  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?

<ALEX> The security considerations are just that – considerations.  The point here is that security per se can be subjected to intent, like any other network aspect.  How security would be expressed is beyond the concept itself.  We can certainly point that out.  Again, it is one of the items that I think involve also questions for research.
</ALEX>

  1.  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?

<ALEX> Not sure what you are asking here.  Obviously, if the party that expresses intent has been compromised there is an issue, but I would consider this outside the framework itself.  Obviously, the source of the intent needs to be authorized, authenticated etc.
</ALEX>

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.

<ALEX> Many thanks for your comments, and again my apologies for the time lag in responding (I was on PTO when you sent the message and it just fell through the cracks on my end).
</ALEX>
Stay healthy!

Best regards,

Ali