[Detnet] DetNet Security Considerations 17Dec19 call notes

["Grossman, Ethan A." <[e-mail]>]

Hi All,
Here are my notes on the DetNet Security call we had last week (attendees: Stewart Bryant, David Black and me). Thus far I have not made any changes to the draft, because the implications of the discussions below, if implemented, could result in a significant revision of the draft, and I would like to hear what y'all think about the proposed direction. So please put in your $0.02.
Jean-Yves, if you're out there, I would be particularly interested in your input since I know you have experience with observing non-DetNet-WG peoples' reactions to the draft in its current form.
Reminder that we have scheduled another call for Tuesday Jan 21, 2020, 10am.
Thanks,
Ethan (as DetNet Security Draft editor)
-----------------------------------------------------------------------

  *   On recommendation for using IPSec for DetNet IP - problem: Can't see enough of the flow to do flow differentiation; e.g. need 6tuple but is always hidden in IPSec. Lou wrote that section, need to check with him.
  *   We want to set the initial expectation that the DetNet network to be secured is already a well-designed and well-managed network (other possible phrasing: "a traffic-managed, controlled environment" or "a traffic-engineered network") following existing best practices. We assume that all such relevant characteristics are in place as a starting place for this DetNet Security Considerations draft/discussion. We can thus simplify our draft by setting this assumption. Having the draft be shorter is a positive step.
  *   Regarding control plane - we can state that every Control Plane has to be well managed and secured by industry standard practice - this removes the need to say a lot of the specific things we say in the draft.
  *   We want to the initial expectation that the reader will be familiar with the DetNet Use Cases draft, because that is where the "expectations" (not saying "requirements") regarding security are stated, since there is no DetNet Security Requirements ("Expectations") draft. (As a result, our intention is to remove Sec 8. Appendix A: DetNet Draft Security-Related Statements from the draft - any objections to that?) In review if someone says something about lack of specific security "requirements" to review the draft against, we can point to the Use Cases drafts. (This is normal in IETF specs - each RFC is a chapter in the book, assumed reader will read all of chapters. Contrast with other organization specifications which are more self-contained).
  *   An MPLS network is inherently more secure than an IP network, because with MPLS it is difficult to introduce a rogue LSR or PE into the network, compared with IP, in which a random device is less difficult to introduce onto the network (and from there send packets into the network). An MPLS network is highly managed by its provider, e.g. BT, ATT, etc. Nothing gets in there.
  *   In contrast to a PW model for MPLS, an IP model can be thought of as an overlay model, so the goal is to protect the overlay forwarding resources. To do that, we need to manage the network as tightly as an MPLS network, equivalent to MPLS-TE. Need to have that as a starting point - should be "this is a mega tight network, nothing gets in that we don't allow in".
  *   Another way to phrase this is like "with a standard IT network, we manage it at least as well as a VPN". We have a lot of experience with VPNs running through networks with other VPNs, we know how to do that. Perhaps this could be pointed out somewhere near the text that says that legacy OT networks are "isolated" (meaning "air gapped") (from e.g. the IT network) and are thus less susceptible to attack.  Assume VPN characteristics, but note that any "bumping into" (interference) of one packet with another can have an effect.
  *   Network slicing - could this be used for DetNet? Or is it that DetNet could be used to implement slicing? This is a meta-problem at architecture level; Perhaps the world has changed since Arch doc was written. Lots of people working on slicing now, e.g. for 3GPP. Perhaps Lou's work in TEAS on TE'd VPN is relevant? Two strategies for this: Classical MPLS model vs SR model. Issue of stealing resources - we could describe this as an issue, or maybe could even refer to slice drafts, but we don't want to be held up by those drafts. Point is that others are thinking about this.
  *   Draft needs to set out principles, good quality abstract models, rather than details; currently the draft has too many details. Not enough focus on delay and packet loss considerations, which are the core. Current draft focus is explicit on "now" technologies, as opposed to setting considerations for any technology. Need to establish  what they need to do to conform to security considerations. Current draft is drilled down into classical existing world, perhaps not the world we will find in the future. Need to review what we can assume is known, and what we have to do to encompass various technologies.
  *   Section 3 - seems like a basic tutorial on security threats? Is that level of tutorial needed, given the expectations set above? For example Internal vs external, access to segments, all standard in secured traffic engineered MPLS networks. Can assume that is taken care of. But delaying a packet is more significant, can be very subtle, need to focus more on that.
  *   Regarding DetNet to transfer clocking - could be beneficial to clock distribution, however if using PREOF then it could be detrimental to clock sync and ranging. Need to teach people that there are limitations - is this the place for that? We are clear that we are not addressing how time is to be distributed in a DetNet network, but maybe a caveat is in order? Clock xfer is subtle, few understand it.
  *   Not discussing what a data plane needs to do or how it would do it, but describe properties it needs to have in order to conform to security properties or expectations or needs. That is, we need to state expectations of DP, how it would meet requirements, but if it can't, how it would mitigate them. For example, consider a requirement for "IT traffic must not affect DetNet traffic". So a possible implementation, as one would do in a non-time-sensitive network is to put them in their own VPNs or MPLS tunnels to ensure they run independently. However DetNet special since packets "bumping into" other packets can be a problem.  We need to say that they have to provide this isolation, but not how to provide it. So we can say something like "forwarding bandwidth (and related resources) must be protected so that they are available to detnet traffic". How they do it is up to the dataplane designers. Otherwise we end up committing to solve an infinite number of problems, and possibly limit options of designers to innovate or otherwise solve problems.
-----------------------------------------------------------------------