Deterministic Networking (DetNet) Security Considerations
draft-ietf-detnet-security-16

[Ballot comment]
There are probably a couple places that currently reference only RFC 8939
where it would be appropriate to reference both 8939 and 8964.

Section 1

  This document is based on the premise that there will be a very broad
  range of DetNet applications and use cases, ranging in size scope
  from individual industrial machines to networks that span an entire

nit: s/size scope/size and scope/

Section 4

  DetNet is designed to be compatible with DiffServ [RFC2474] as
  applied to IT traffic in the DetNet.  DetNet also incorporates the
  use of the 6-bit value of the DSCP field of the Type of Service (ToS)
  byte of the IPv4 header (or the Traffic Class byte in IPv6) for flow
  identification for OT traffic.  [...]

nit: I suggest "the use of the 6-bit value of the DCSP field of the Type
of Service (IPv4) and Traffic Class (IPv6) bytes for flow
identification", to avoid giving IPv4 preferred treatment.

Section 5.2.3

  However if there is only one queue from the forwarding ASIC to the
  exception path, and for some reason the system is configured such
  that DetNet packets must be handled on this exception path, then
  saturating the exception path could result in delaying or dropping of
  DetNet packets.

nit: I suggest "such that some DetNet packets" -- it is an issue if any
do, and doesn't require all of them to take the exception path.

Section 6.1.1

  A data-plane delay attack on a system controlling substantial moving
  devices, for example in industrial automation, can cause physical
  damage.  For example, if the network promises a bounded latency of
  2ms for a flow, yet the machine receives it with 5ms latency, control
  loop of the machine can become unstable.

nit: "the control loop".

Section 7.2

      There are different levels of security available for integrity
      protection, ranging from the basic ability to detect if a header
      has been corrupted in transit (no malicious attack) to stopping a
      skilled and determined attacker capable of both subtly modifying
      fields in the headers as well as updating an unsigned MAC.  [...]

I'd suggest s/unsigned MAC/unkeyed checksum/.

Section 9.2

It's a bit surprising to not see references to the (security
considerations of the) MPLS control word specs like RFCs 4385 and 5586.

[Ballot comment]
Thank you to Yaron Sheffer for the SECDIR review.  Please respond to it.

Thanks for addressing my DISCUSS points and a number of my COMMENTs.


===

** Section 7.4.  The use of [IEEE802.1Qch-2017] is remarkably specific reference without any guidance on implementation, either here the active DetNet drafts (I checked).  Please consider if this is realistic guidance without further citation on how this could be implemented.

[Ballot discuss]
We say that we adhere to the guidelines of RFC 3552, yet we do not
mention that it may be impossible to achieve our goals "in the face of a
highly capable adversary, such as the one envisioned by the Internet
Threat Model of BCP 72 [RFC3552] that can arbitrarily drop or delay any
or all traffic" (to quote from a recent DetNet RFC that does cover this
topic, RFC 8939).  I think that in order to fully adhere to RFC 3552, we
need to be more explicit about how we have to assume a reduced attacker
capability set in order to make any progress at all.  A good place for
this discussion would be near where we state that security a DetNet
starts with a scrupulously well-designed and well-managed engineered
network in Section 1 -- the goal of having the well-managed network is
to exclude some of the more powerful adversary capabilities from the
Internet Threat Model.

[Ballot comment]
I agree with the secdir reviewer that additional linkage between threats
that the potential mitigations for them would be useful, albeit somewhat
time-consuming to add.

This is much-improved from the last time I looked at it; thank you for
continuing to make improvements!  I do still have a sizeable number of
comments, though; hopefully they will help to make further improvements.

I suspect that we would do well to reiterate the theme that has appeared
in the security considerations of the several most recent detnet RFCs,
along the lines of "achieving the goals of detnet may not be possible in
the face of a highly capable adversary, such as the one envisioned by
the Internet Threat Model of BCP 72 [RFC3552] that can arbitrarily drop
or delay any or all traffic", especially since we say that we otherwise
adhere to RFC 3552's guidelines.  A good place for this discussion would
be near where we state that security a DetNet starts with a scrupulously
well-designed and well-managed engineered network in Section 1 -- the
goal of having the well-managed network is to exclude some of the more
powerful adversary capabilities from the Internet Threat Model.  We
should say that explicitly.

Section 2

  Resource Segmentation Used as a more general form for Network

nit: missing colon

Section 3.3

  be protected by using MACsec [IEEE802.1AE-2018].  Similary, from the
  sequence number injection perspective, it is no different from any
  other protocols that use sequence numbers.

Many other protocols that use sequence numbers are in practice
vulnerable to sequence number injection.  Having specific references to
other protocols that are protected against such injection seems like it
would be useful.

Section 4

                                                        However DetNet
  also introduces timing and other considerations which are not present
  in DiffServ, so the DiffServ security considerations are necessary
  but not sufficient for DetNet.

In my experience, security considerations are typically statements of
fact about the properties of a protocol/system, as opposed to
requirements for secure operation; in that context it is better to say
that the diffserv security considerations are a subset of the detnet
security considerations, as opposed to the current "necessary but not
sufficient" phrasing.

                                    In DetNet, there are similar
  consequences to DiffServ for lack of detection of, or incorrect
  handling of, packets with mismarked DSCP values, and many of the

If I understand correctly, the detection/handling in question here is
specifically at ingress to the domain?

Section 5.1

[I'll note for completeness that I still would prefer this to be called
a taxonomy of threats rather than a threat model, but we've had the
conversation about how this formulation is analogous to that of RFC 7384
and there's nothing left to say.  No response needed; I'm just recording
that we agreed to disagree.]

  o  Internal vs. external: internal attackers either have access to a
      trusted segment of the network or possess the encryption or
      authentication keys.  External attackers, on the other hand, do
      not have the keys and have access only to the encrypted or
      authenticated traffic.

I think it is common to use "external" to refer to attackers that are
entirely outside of a domain and are limited to attmping to send packets
into the domain, with no visibility into legitimate traffic inside the
domain.  The description here suggests that the boundary between
"internal" and 'external" is more of a logical one, perhaps relating to
access to physical packets (in encrypted form) vs unprotected packts (as
available to internal systems), but perhaps there is intended to also be
a "secure network" where the physical packets contain the logical data
but are physically inaccessible to the attacker.  Section 5.3 alludes to
the existence of some "security mechanism" that provides the boundary
between external and internal attackers, but leaves the actual nature of
the boundary unclear, for me.
[This looks like it's basically the same as Roman's first discuss point,
which I support.]

  o  On-path vs. off-path: on-path attackers are located in a position
      that allows interception and modification of in-flight protocol
      packets, whereas off-path attackers can only attack by generating
      protocol packets.

We sometimes differentiate between (e.g.) "active" or "passive" on-path
attackers, where interception/viewing is done in either form but
modification only done in the "active" form.

Section 5.2.3

I don't understand why the section title includes "Resource
Segmentation"; the scenario being described seems to discuss risks that
are present when resources are *not* properly segmented.  Resource
Segmentation by itself should not be a threat in this regard.

  An attacker can inject traffic that will consume network resources
  such that it affects DetNet flows.  This can be performed using non-
  DetNet traffic that indirectly affects DetNet traffic (hardware
  resource exhaustion), or by using DetNet traffic from one DetNet flow
  that directly affects traffic from different DetNet flows.

I don't understand what is meant by "detnet traffic from one flow that
directly affects traffic from different detnet flows".  How might this
happen?

Section 5.2.4.2

      bridge, the flow is hijacked by the attacker.  It is now posible
      to either replace en route packets with malicious packets, or
      simply injecting errors, causing the packets to be dropped at
      their destination.

nit: s/injecting/inject/

Section 5.2.5.2

  An attacker can subvert a controller, or enable a compromised
  controller to falsely represent itself as a controller so that the
  network nodes believe it to be authorized to instruct them.

I can't tell if "compromised controller" was a typo that was supposed to
refer to some non-controller class of entity, so that the false
representation as a controller is a significant change in node
capability.

Section 5.2.6

  A passive eavesdropper can identify DetNet flows and then gather
  information about en route DetNet flows, e.g., the number of DetNet
  flows, their bandwidths, their schedules, or other temporal
  properties.  [...]

I suggest "other temporal or statistical properties" to encompass things
like latency and jitter, which are only in some limited sense temporal
properties.

  DetNet flows are typically uniquely identified by their 6-tuple, i.e.
  fields within the IP header, however in some implementations the flow
  ID may also be augmented by additional per-flow attributes known to
  the system, e.g. above the IP-layer.  [...]

pedantically, the ports in the 6-tuple are also above the IP layer.

                                        For the purpose of this
  document we assume any such additional fields used for flow ID are
  encrypted and/or integrity-protected from external attackers.

I suggest adding a note that existing OT protocols designed for use on
dedicated secure networks may not intrinsically provide such protection,
in which case IPsec or transport layer security mechanisms may be
needed.  (I do see a note on a similar or more generic topic already in
§6, but don't think there is harm in having another one.)

Section 5.3

How can an off-path attacker perform a delay attack?

Section 6

What is the distinction between "Health and Safety" and "People Well
Being"?

  Safety, People well being (People WB), Affect on a single
  organization, and affect on multiple organizations.  Recovery

nit: s/Affect/Effect/ in both lower and upper case forms (the table,
fortunately, is already correct)

Why is M2M control listed as only having low impact from data integrity?
I would have thought that integrity of the control plane information
would be pretty important.

Section 6.1.1

  For a single path scenario, disruption is a real possibility, whereas
  in a multipath scenario, large delays or instabilities in one DetNet
  flow can lead to increased buffer and processor resources at the
  eliminating router.

nit: I think s/resources/resource consumption/

Section 6.2.1

I think it might be more interesting to mention the scope of potential
harm when the corrupted or modified payloads are interpreted, rather
than just saying that they could be modified.

Drvyion 6.3.2

I think the primary concern here is that there will be skew between the
"reality" in the individual nodes and the expected state known to the
controller, such that when the controller attempts to make changes in
the future the actual actions will differ.  The specifics of how the
initial skew occurs is less interesting, and essentially equivalent to
the spoofing case.

Section 6.4.x

I think the referenced coverage is perhaps too brief to be useful.

Section 6.8

In the context of this section, we should be talking about the
discussion or description of the impact of attacks; how attacks are
"addressed" would be analogous to the mitigations that we cover in §7.

Section 7.2

      An integrity protection mechanism is designed to counteract header
      modification attacks where a Message Authentication Code (MAC) is
      the most common.  [...]

nit: the "a MAC is most common" seems to bind to "header modification
attacks", not "integrity protection mechanism; I suggest
NEW:
      An integrity protection mechanism is designed to counteract header
      modification attacks.  A Message Authentication Code (MAC) is
      the most common such mechanism.

                        The MAC can be distributed either in-line
      (included in the same packet) or via a side channel.  Due to the
      nature of DetNet traffic.  [...]

nit: incomplete sentence?

      replication attacks (see Section 5.2.2 and Section 5.2.4).  This
      MAC usage needs to be part of a security association that is
      established and managed by a security association protocol (such
      as IKEv2 for IPsec security associations).  Integrity protection

BCP 107 might be a good reference here.

      sequence numbers are not modifiable.  Thus, sequence numbers can
      be protected by using encryption, or by a MAC without using

I suggest s/encryption/authenticated encryption/; an unqualified
"encryption" is easy to interpret as something like a stream or block
cipher mode without integrity protection, which is malleable without
detection.

      encryption.  Between the adder and remover there may or may not be
      replication and elimination functions.  The elimination functions
      must be able to see the sequence numbers.  Therefore, if
      encryption is done between adders and removers it must not obscure
      the sequence number.  If the sequence removers and the eliminators
      are in the same physical component, it may be possible to obscure
      the sequence number, however that is a layer violation, and is not
      recommended practice.  [...]

It would also be technically feasible (but very ill-advised) to share
the encryption key with the elimination function and continue to use
encrypted sequence numbers.  This is ill-advised because two-party
security with a shared symmetric secret provides much stronger peer
authentication than group seciryt with a shared symmetric secret.

Section 7.4

I suggest reiterating that it is expected that cryptographic
confidentiality protection is applied to traffic; dummy traffic is
generally ineffectual when the plaintext is visible to the attacker.

Section 7.5

      Note that reconnaissance is a threat that is not specific to
      DetNet flows, and therefore reconnaissance mitigation will
      typically be analyzed and addressed by a network operator
      regardless of whether DetNet flows are deployed.  [...]

nit: I suggest s/addressed/provided/ since "addressed" usually implies
that the thing in question is a problem that needs to be mitigated, but
we are describing the mitigation itself.

Section 7.5.1

  Any compute time which is required for encryption and decryption
  processing ('crypto') must be included in the flow latency
  calculations.  Thus, crypto algorithms used in a DetNet must have
  bounded worst-case execution times, and these values must be used in
  the latency calculations.

(In general, crypto operations should have constant execution times, to
avoid side channel leakage.)

  If crypto keys are to be regenerated over the duration of the flow
  then the time required to accomplish this must be accounted for in
  the latency calculations.

[In contrast to my previous comment, key generation is a cryptographic
operation that is frequently not possible to implement in constant time,
most notably thoguh not exclusively for RSA key pairs.]

Section 7.7

      Making DPA measurement results available at the right place(s) and
      time(s) to effect timely response can be challenging.  Two
      notification mechanisms that are in general use are Netconf/YANG
      Notifications (e.g.  [RFC5880]) and the proprietary local
      telemetry interfaces provided with components from some vendors.

I think that CoAP Observe (RFC 7641) could also apply to such scenarios,
but I don't have enough information to be able to say whether it is "in
general use" for this purpose.

      Performance analytics can be used to mitigate various attacks,
      including the ones described in Section 5.2.1 (Delay Attack),
      Section 5.2.3 (Resource Segmentation Attack), and Section 5.2.7
      (Time Synchronization Attack).

Mitigate, or just detect?  (May also affect Figure 3.)

Section 7.8

In my mind the "Replication: increased attack surface" attack included
the potential for the replicated data stream to be available (and thus
subject to reconnaissance) in more places, in addition to there being
more devices relevant to a given flow and susceptible to attack.  In
that case, encryption would also be a relevant mitigation, but it is not
currently listed as one.

We list "control message protection" as a potential mitigation for
several rows in the table, but I do not see where there is prose
discussing what that mitigation entails.

Section 8.1.1

Some subnetwork layers other than ethernet might have additional attacks
and impacts that are not relevant to ethernet.  A prominent example
would be radio technologies, where the broadcast domain is "anyone with
an antenna", though this is probably not the only example of affected
subnetwork technology or additional attack/impact.

Section 8.1.3

  To mitigate this situation, deployments should provide a method for
  dynamic and secure registration of new components, and (possibly
  manual) deregistration of retired components.  This would avoid the
  situation in which the network must accommodate potentially insecure
  packet flows from unknown components.

[The IETF has specified a number of enrolment and bootstrapping
protocols (EST, BRSKI, SZTP, CMC, CMP, etc.), though it's not clear that
it's helpful to informatively reference any particular ones, here.]

Section 8.1.5

  Please note that although there are no entries in the L2 and L3
  Integration line of the Mapping Between Themes and Attacks table
  Figure 4, this does not imply that there could be no relevant attacks
  related to L2-L3 integration.

Very true -- thank you!

Section 8.1.6

  It may be that such attacks are limited to Internal on-path
  attackers, but other possibilities should be considered.

Why is this listed as "may be"?  What factors influence whether it can
or cannot be the case?

Section 8.1.8

  However the handling of IT traffic by the DetNet may not (by design)
  be as resilient to DOS attack, and thus designers must be otherwise
  prepared to mitigate DOS attacks on IT traffic in a DetNet.

I don't think I understand what this is trying to say.  Both for what
behavior is "by design" and what designers are expected to do.

Section 8.1.10

  is made available on the network for best-effort traffic.  However,
  note that security considerations for best-effort traffic on a DetNet
  network is out of scope of the present document, provided that such
  an attack does not affect performance for DetNet OT traffic.

nit: there's no antecedent for "such an attack" that I can see.

Section 8.1.13

The usage of 'secure" and "security layer" in this section are pretty
vague as to what properties are implied.  Can we be more precise?

Section 8.1.15

  An attack that takes advantage of flaws (or even normal operation) in
  the device drivers for the various links (through internal knowledge
  of how the individual driver or firmware operates) could take
  proportionately greater advantage of this topology.

I don't really understand what is meant by "proportionately greater
advantage of this topology"?  What is being compared to?

Section 8.2

Is a delay attack relevant for deterministic flows?

How is a reconnissance attack relevant for low latency?

Section 9.2

  The operation of DetNet over an MPLS network is modeled on the
  operation of multi-segment pseudowires (MS-PW).  Thus for guidance on
  securing the DetNet elements of DetNet over MPLS the reader is
  referred to the MS-PW security mechanisms as defined in [RFC8077],
  [RFC3931], [RFC3985], [RFC6073], and [RFC6478].

I'm not sure I saw which security mechanisms are supposed to be provided
by RFC 3985 and/or RFC 6478 (though I only very quickly skimmed through
them).

  Further consideration of protection against dynamic attacks is work
  in progress.  New work on MPLS security may also be applicable, for
  example [I-D.ietf-mpls-opportunistic-encrypt].

I got excited by the draft-ietf-mpls-opportunistic-encrypt reference,
but following the link suggests that the draft has been expired for
three years.  Is it still appropriate to refer to it as "new work" or
"work in progress"?

Section 12

Traffic analysis and similar side channels can still cause there to be
privacy considerations even when traffic is encrypted.

[Ballot comment]
I did not have time to review this document in detail but I looked at the Gen-ART review and it seems that most of the points have been addressed, thanks. I agree with other ADs that the tables in Section 6 do not make much sense or add much value. At a minimum the block chain and networking slicing columns should be removed as they are provided with no explanation and do not seem to belong with the other columns.

[Ballot comment]
Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

Let's also try to address the COMMENT for section 4.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1 --
In "best practices for security at both the data plane and controller plane", is there a reason why the management/telemetry plane(s) is not included? Of course, most of the time this plane is isolated from the others but anyway... Also, is is "controller plane" or "control plane" ? or is the 'controller plane' the plane connecting PCC to PCE ? (with an assumption that the ID is also relying on PCC/PCE ?).

Section 8.3 (OAM) is welcome but why not already including OAM in the above sentence ?

-- Section 5.2.3 & 6.3.1 --
May I assume that any layer-1 'jamming' (e.g., microwave link) is also covered by this section ? If so, then I suggest to state it.

-- Section 3.3 --
"(Note that PREOF is not defined for a DetNet IP data plane)." will this note be applicable forever ? Should the word 'currently' be used in this statement? I also do not see the point of using parenthesis. I prefer the wording used in section 7.1 "At the time of this writing, PREOF is not defined for the IP data plane."

-- Section 3.4 --
Probably due to my ignorance about DetNet, but, I fail to understand why "having the network shut down a link if a packet arrives outside of its prescribed time window" and the rest of the section. Again, probably due to my lack of context but you may want to explain the reasoning behind.

-- Section 4 --
There is no 'TOS' field in the IPv6 header, it is replaced by 'Traffic Class'. So, please mention both of the fields.

-- Section 6 --
On figure 2, there are mentions of blockchain and network slicing without any previous explanations (and I have hard time to see how blockchain traffic should be detnet).

-- Section 8.3 --
This section seems to consider only OAM traffic added to the DetNet traffic while there are a couple of in-band OAM techniques currently being specified at the IETF.

-- Section 9 --
If the IPsec sessions are established by a controller, then this controller could also send the Security Parameter Index (SPI) that is transmitted in the clear and use this SPI to in addition to the pair of IP addresses.

== NITS ==

-- Section 1 --
s/A DetNet is one that/A DetNet is a network that/

-- Section 8.2 --
s/Figure 5maps/Figure 5 maps/

-- Authors --
The URL for http://www.mistiqtech.com does not work for me

[Ballot comment]
Thanks for this document.  Sorry, I've run out time to review this in detail, although I don't immediately see any manageability concerns when I scanned through the document.

A few minor comments for your consideration:

1) Perhaps it might be helpful to mention remind that DetNet isn't the same as TSN in the introduction?

I don't know if these are already covered, or if they are not valid problems, but I guess a couple of attacks that I would be concerned with are:

(2) Overloading the exception path queue on the router.  E.g., if any of the DetNet streams require/expect some packets to be punted to the control plane or software data plane for processing (OAM related perhaps), and there is a single queue from the forwarding ASIC to a control plane or software data plane, then it could be possible for Non Detnet flows to overload that shared queue such that punted packets on the DetNet flows would end up being dropped.

(2b) Related to (2), if an attacker was able to overload the router or linecard CPU, e.g., through excessive management API requests, then it may be plausible that it could also cause control plane processing of packets to be dropped, or slowed down.

(2c) If the control plane is being managed by a separate controller than presumably both (2) and (2b) could equally apply to getting traffic to a controller, or processing events on the controller.

(3) Is there any potential issue with traffic being carried over L2 load balanced links (e.g. LAG) that apply statistical QoS.  E.g., by crafting traffic on a non DetNet flow that overloads one LAG member but doesn't overload the statistical QoS guarantees.  Perhaps this is outside the considerations for DetNet, or already covered by TSN.

I'll leave it to the authors to determine whether any of these are valid and require further text, or if they are either already sufficiently covered, out of scope, or not valid concerns.

Regards,
Rob

[Ballot discuss]
** Section 5.1 and Figure 1.  Thanks for separating the different kinds of attackers.  As it relates to “internal vs external” where are the details of what DetNet traffic is encrypted or authenticated to create a distinction between internal and external; and to rule out certain attack to external actors per Figure 1?

** I may not fully understand the architecture, but these threats and mitigations didn’t seem to align:

--  Section 7.1.  Per path redundancy being able to mitigate Section 5.2.7 (time sync), which is just reference to RFC7384, how does a RFC8655 style PREOF mitigate a grandmaster time source attack per Section 3.2.10 of RFC7384?  Is the intent here that all RFC7384 attacks are mitigated?

-- Section 7.5.  “Reconnaissance attacks (Section 5.2.6) can be mitigated by using encryption” seems like too strong of a statement.  Some traffic analysis should be still be possible.

-- Section 7.6.  Per “These mechanisms can be used to mitigate various attacks on the controller plane as described in Section 5.2.5 …”, can it be clarified how these security properties will protect against controller compromise (Section 5.2.5.2).

[Ballot comment]
Thank you to Yaron Sheffer for the SECDIR review.  Please respond to it.

** Section 3.  I had difficulty extracting what security considerations are being conveyed and the assumptions being made in this section.  Specifically, what was assumed to be a prerequisite for DetNet (and out of scope), what is a required security property engineered into the DetNet protocols, and what might be a necessary behavior for operators of DetNets.  Put in another way:

-- Is this section documenting the properties of a DetNet that system security designer can assume if they deploy some combination of the protocols of the DetNet WG?

-- Is this section documenting the security properties of the protocols coming out of the drafts in the WG?

-- Is this section documenting requirements for implementers (component designers)?

-- Is it documenting the “assumed scrupulously well-designed and well-managed engineered network following industry best practices for security at both the data plane and controller plane; this is the assumed starting point for the considerations discussed herein” (per Section 1)?

Another example of my confusion is in Section 7.2.  Given the abstract text, it is unclear who is supposed to be using this guidance

** Section 3.1.  I’m having difficulty reconciling:

(a) “in other words there is no physical possibility within a DetNet component that a resource allocated to a given flow can be compromised by any traffic in the network”

(b) “it is the responsibility of component designers to ensure that this condition is met … for example through the use of traffic shaping and policing”

To me,  (a) suggests formal verification or something that must burned in silicon since there is “no physical possibility”.  However, the example in (b) which seems like a means to implement that goal reads a lot weaker like standard operational practices even on IT networks.

** Section 3.2.  If the “[T]he system designer relies on the premise that the packets will be delivered with the specified latency boundaries” and this is an assumption, what security consideration is there?  The property seems to be either an out-of-scope article of faith or a requirement.

** Section 3.4.  This isn’t framed in terms of system or component designers like the other sub-sections of Section 3.  Can the actors be clarified?

** Section 5.1.  The more detailed text in Section 6 seems to note that traffic might get dropped by an attacker.  Therefore, it is likely worth:

OLD
On-path attackers are located in a position that allows interception and modification of in-flight protocol packets

NEW
On-path attackers are located in a position that allows interception, modification, or dropping of in-flight protocol packets

** Section 5.2.5.2.  Is a compromised DetNet node in the control plan in scope?

** Figure 1.  Is there a reason that the “Compromised Controller” isn’t listed?

** Section 6.  Per “This section describes and rates the impact ...”, what is the intuition on these low, medium, hi? What and who does something with these tables?  What does Lo, Med, Hi mean?

** Section 6.  Per “In computer security,  the impact (or consequence) of an incident can be measured in loss of confidentiality, integrity or availability of information.  In the case of time sensitive networks, the impact of a network exploit can also include failure or malfunction of mechanical and/or other OT systems”, this reads like a very narrow view of IT network comprise suggestion that only OT system has “real-world” consequences.

** Section 6.  IHMO, the two part table doesn’t add much to the discussion and should be removed. It introduces a new taxonomy of impact without much explanation.  There is no tangible guidance to the “component designer” or “system designer” on how to parse the “low, medium, high”.  Ultimately, as the text says “[i]n practice any such ratings will vary from case to case; the ratings shown here are given as examples”.  Even as an example, there is no guidance on how the intended audience would use this information.  Additionally, there is little mention of many of these impacts in the details of Section 6.*

** Section 6.7.  What is the basis for concluding that reconnaissance will lead to ransom attack as opposed to any of the other attacks mentioned in this section?

** Section 7.1.  Per “Path replication and elimination [RFC8655] provides resiliency to dropped or delayed packets”, I found no reference to the “path replication” in RFC8655.  What Section 3.2.2.2 of RFC8655 does seem to talk about is packet replication.  Should the same words be used for consistency?

** Section 7.1.  Per path redundancy being able to mitigate Section 5.2.2 (flow modification or spoofing) where is the approach to reconciling the two packets, one modified and another not, per the notional PREOF functionality?

** Section 7.2.  Given the abstract nature of this text, should it be read as a requirement?  Who is this requirement for, adding a MAC to protocol is a design issue but rely only IPSec can be handled in operation

** Section 7.4.  The use of [IEEE802.1Qch-2017] is remarkably specific reference without any guidance on implementation, either here the active DetNet drafts (I checked).  Please consider if this is realistic guidance without further citation on how this could be implemented.

** Section 7.5.1.  Will the intended audience of this section roll their own encryption primitives or invent their own protocol?  If not, it might be more useful to discuss concrete protocols that will secure the communication with the properties desired.

** Section 7.7.  Per “Performance analytics can be used to mitigate various attacks, including the ones described in Section 5.2.1  ...”, this language seems imprecise.  The DPA can likely detect the delay attack, but this text doesn’t describe it having the capability to mitigate it (i.e., the difference between a IDS and IPS system)

** Section 8.1.  What is the basis for the list in 8.1.*?  What is a “Use Case Common Theme”?  Why for example wouldn’t virtualization (of say the controller) be “a common theme”?

** Section 8.1.3.  There might be rekeying issues to also manage when swapping of components.

** Section 8.1.4.  Per “DetNet specifies new YANG models which may present new attack surfaces ”, what and where are these new YANG models?

** Section 8.1.6.  What is a “Flow Modification attack” (only time this term is used in the document) and how is that related to the threat analysis in Section 5.2?

** Section 8.1.23.  “A DetNet network must be made sufficiently secure against problematic component or traffic behavior, whether malicious or incidental, and whether affecting a single component or multiple components.”  IMO, this paragraph is so generic and the definition of a component per Section 2 is so expansive that this lacks meaning (beyond saying “security is needed”).  It doesn’t seem actionable to implementers (component or system designers).

** Typos

Section 3.3. Typo. s/reliablity/reliability/

Section 3.3.  Typo. s/arrangment/arrangement/

Section 3.3. Typo. s/reliabiilty /reliability/

Section 3.3.  Typo. s/Similary/Similarly/

Section 5.2.4.2.  Typo. s/elminating/eliminating/

Section 5.2.4.2.  Typo. s/posible/possible/

Section 5.2.4.2.  Typo. s/elminating/eliminating/

Section 5.2.4.2.  Typo. s/posible/possible/

Table 2.  Typo. s/Effect 1/Affect 1/g

Section 6.2.2.2.  Typo. s/potentionally/potentially/

Section 8.1.2.  Typo. s/ Reconaissance/ Reconnaissance/

[Ballot comment]
I found this to be an interesting read.  Once you mentioned aircraft internals, I was even more into it.

This text in the Abstract caught my eye:

  This document also addresses security considerations specific to the
  IP and MPLS data plane technologies, thereby complementing the
  Security Considerations sections of those documents.

It almost seems appropriate for this one to formally update those if indeed they were left incomplete.  I realize, however, that's not possible for an Informational document if the others are Standards Track.

Besides that, some nits:

Section 8.1.8: s/coexistance/coexistence/

In Section 8.1.11, there's an instance of DETNET in all-caps, while it's "DetNet" everywhere else.

Section 8.1.22, a suggestion:

OLD:

  [...] A strategy used by DetNet
  for providing such extraordinarily high levels of reliability is to
  provide redundant paths that can be seamlessly switched between, all
  the while maintaining the required performance of that system.

NEW:

  [...] A strategy used by DetNet
  for providing such extraordinarily high levels of reliability is to
  provide redundant paths between which traffic can be seamlessly
  switched, all the while maintaining the required performance of that system.

[Ballot comment]
It's interesting to collect security considerations into one document.  We have to be careful that in doing so, we don't fall into the trap of not thinking enough about security considerations specific to later documents, once this one is published and immutable.  Let's please watch for that.

I'm also interested to see the discussion of Magnus's DISCUSS points.

And just a few editorial comments about the Introduction:

  A DetNet is one that can carry data flows for real-time applications
  with extremely low data loss rates and bounded latency.

I would spell it out first” “A Deterministic Network (DetNet) is one…”

  potentially bringing the OT
  network into contact with Information Technology (IT) traffic and
  security threats that lie outside of a tightly controlled and bounded
  area (such as the internals of an aircraft).

It’s not clear from the sentence structure what “the internals of an aircraft” is meant to be an example of.  Is it an example of a tightly controlled and bounded area (as it seems it would be)?  Or is it outside that?  And if it’s not outside that, what’s the point of using it as an example?  Are you meaning to say that we have to deal with threats from outside that affect things inside the tight boundaries?

Maybe it’s best to try to reword this?

  following industry best practices for security at both the data plane
  and controller plane;

This should be “control plane”, shouldn't it?  Also in other places in the document.

[Ballot discuss]
Section 3.1:

  A DetNet system security designer relies on the premise that any
  resources allocated to a resource-reserved (OT-type) flow are
  inviolable, in other words there is no physical possibility within a
  DetNet component that resources allocated to a given flow can be
  compromised by any type of traffic in the network; this includes both
  malicious traffic as well as inadvertent traffic such as might be
  produced by a malfunctioning component, for example one made by a
  different manufacturer.

Can we really ensure that a malfunctioning component can't compromise the resources of another one. The most simple example I would have is a router with a malfunction rewriting the destination address or flow label of a packet causing the packet to change the flow it is belonging too, thus if occurring for any significant amount of packets causing overflow in the next hop router when the original and the remarked flow compete for the same resources assigned. The only way to ensure that this happens is to verify a strong header integrity protection at each point a decision on how to forward, classify or remark the flow is done. So Section 3.3 indicate that this is an issue, but only discusses how it can be solved over ethernet. This issue hasn't been well handled in either the MPLS or IP detnet data planes as no additional mechanism was required to ensure this criteria is meet.

So I think the requirement that also malfunctions in equipment don't result in flow violations is hard, and will require that the already approved data plane specification needs additional mechanism that verify all data used on each occasion the data is used. Neither MPLS nor IP as currently specified fulfill this, not even against non-malicious malfunctions or corruption type malfunctions. Then we have those malfunction that breaks the network or where control plane information provided is being corrupted.

I have only looked a bit deeply on one type of malfunction that I know that can occur. I convinced that this document will indicate a number of additional potential ways things can go wrong that can't be determined without additional mechanisms and likely additional per packet fields. Thus, I think we need to discuss if the security properties matches the actual approved data plane, or if the property is so important that the data plane specification is moved back to the WG to be fixed?

I would also recommend that you don't indicate that a different manufacturer can be blamed. Isn't a malfunction going to occur where they occur, it is not like a single vendor network will be without malfunctions due to hardware issue, nor have its set of software bugs.

Section 9.1:


  The IP protocol has a long history of security considerations and
  architectural protection mechanisms.  From a data plane perspective
  DetNet does not add or modify any IP header information, so the
  carriage of DetNet traffic over an IP data plane does not introduce
  any new security issues that were not there before, apart from those
  already described in the data-plane-independent threats section
  Section 5, Security Threats.

The above requirement from Section 3.1 in regards to IP header fields used for flow classification are not automatically fulfilled without additional mechanisms. Thus, I would claim that DETNET unless Section 3.1 requirement is minimized will require support for a strong integrity mechanism over all headers. So if this needs to be keyed or not is totally dependent on if malicious modifications of packet headers needs to be taken into account or not.

Section 9.2:

Same as previous issue but for integrity over the MPLS headers.

[Ballot comment]
8.1.6.  End-to-End Delivery
Packets sent over DetNet are not to be dropped by the network due to
  congestion.  (Packets may however intentionally be dropped for
  intended reasons, e.g. per security measures).
Maybe it need to be stated that packets for a flow that are within flow parameters are not to be dropped due to congestion.

The security aspects include packets being dropped due to corruption malicious or not.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-detnet-security-12, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-10-27):

From: The IESG
To: IETF-Announce
CC: detnet@ietf.org, lberger@labn.net, Lou Berger , detnet-chairs@ietf.org, draft-ietf-detnet-security@ietf.org, db3546@att.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Deterministic Networking (DetNet) Security Considerations) to Informational RFC


The IESG has received a request from the Deterministic Networking WG (detnet)
to consider the following document: - 'Deterministic Networking (DetNet)
Security Considerations'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-10-27. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  A DetNet (deterministic network) provides specific performance
  guarantees to its data flows, such as extremely low data loss rates
  and bounded latency.  As a result, securing a DetNet requires that in
  addition to the best practice security measures taken for any
  mission-critical network, additional security measures may be needed
  to secure the intended operation of these novel service properties.

  This document addresses DetNet-specific security considerations from
  the perspectives of both the DetNet system-level designer and
  component designer.  System considerations include a threat model,
  taxonomy of relevant attacks, and associations of threats versus use
  cases and service properties.  Component-level considerations include
  ingress filtering and packet arrival time violation detection.  This
  document also addresses DetNet security considerations specific to
  the IP and MPLS data plane technologies thereby complementing the
  Security Considerations sections of the various DetNet Data Plane
  (and other) DetNet documents.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-detnet-security/



No IPR declarations have been submitted directly on this I-D.

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up. Changes are expected over time.

> This version is dated 1 November 2019.

> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Informational

> Why is this the proper type of RFC?

This document provides context for the DetNet WG and has guided the
development of WG data plane documents, but does not itself define any
protocol formats or mechanisms.

> Is this type of RFC indicated in the title page header?

Yes

> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:
>
> Technical Summary:
>
> Relevant content can frequently be found in the abstract and/or
> introduction of the document. If not, this may be an indication that
> there are deficiencies in the abstract or introduction.


  This document addresses DetNet-specific security considerations from
  the perspective of both the DetNet component designer and the DetNet
  system-level designer. this document provides an
  association of threats against various use cases by industry, and
  also against the individual service properties as defined in the
  DetNet Use Cases.

  This document also addresses common DetNet security considerations
  related to the IP and MPLS data plane technologies (the first to be
  identified as supported by DetNet), thereby complementing the
  Security Considerations sections of the various DetNet Data Plane
  (and other) DetNet documents.

> Working Group Summary:
>
> Was there anything in WG process that is worth noting? For example, was
> there controversy about particular points or were there decisions where
> the consensus was particularly rough?

There was significant discussion on what should be in this document and
if it was sufficient.  In the end, the document was indirectly reviewed
by several in the security directorate, as part of their reviews of the
previously submitted (for publication) data plane document and the
general feeling was that this document was in sufficient maturity to be
submitted for publication/

> Document Quality:
>
> Are there existing implementations of the protocol? Have a significant
> number of vendors indicated their plan to implement the specification?
> Are there any reviewers that merit special mention as having done a
> thorough review, e.g., one that resulted in important changes or a
> conclusion that the document had no substantive issues? If there was a
> MIB Doctor, YANG Doctor, Media Type or other expert review, what was its
> course (briefly)? In the case of a Media Type review, on what date was
> the request posted?

The document is one of the foundation documents for other DetNet WG
activities. It notably has had contributions from end-user part of the
market.

> Personnel:
>
>  Who is the Document Shepherd?
Lou Berger

> Who is the Responsible Area Director?
Deborah Brungard

> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd. If this version of the document is not ready for
> publication, please explain why the document is being forwarded to the
> IESG.

I have reread this document as it progressed as well as in its final
form.  All significant comments have been addressed. The document is
ready for publication.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

No. 

> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that took
> place.

While this document has be read/commented on by some in the security
directorate, we certainly expect that it will receive an additional
review as part of normal IESG processing.

> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.

No.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why?

yes, see:
https://mailarchive.ietf.org/arch/msg/detnet/oCh4L5p5qPO26RfV7RDP_UxzRac/


> (8) Has an IPR disclosure been filed that references this document? If
> so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.

N/A.

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others being
> silent, or does the WG as a whole understand and agree with it?

I think the document has good support from active contributors.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)

No.

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

Some of the informational references are to outdated versions.

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type
> reviews.

N/A.

> (13) Have all references within this document been identified as either
> normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state? If such normative
> references exist, what is the plan for their completion?

No.

> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.

No.

> (16) Will publication of this document change the status of any existing
> RFCs? Are those RFCs listed on the title page header, listed in the
> abstract, and discussed in the introduction? If the RFCs are not listed
> in the Abstract and Introduction, explain why, and point to the part of
> the document where the relationship of this document to the other RFCs
> is discussed. If this information is not in the document, explain why
> the WG considers it unnecessary.

No, N/A.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA
> registries. Confirm that any referenced IANA registries have been
> clearly identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 8126).

No requests are made in the document.

> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find useful
> in selecting the IANA Experts for these new registries.

None.

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, YANG modules,
> etc.

N/A

> (20) If the document contains a YANG module, has the module been checked
> with any of the recommended validation tools
> (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
> formatting validation? If there are any resulting errors or warnings,
> what is the justification for not fixing them at this time? Does the
> YANG module comply with the Network Management Datastore Architecture
> (NMDA) as specified in RFC8342?

There are no yang models.

> As required by RFC 4858, this is the current template for the Document
> Shepherd Write-Up. Changes are expected over time.

> This version is dated 1 November 2019.

> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?

Informational

> Why is this the proper type of RFC?

This document provides context for the DetNet WG and has guided the
development of WG data plane documents, but does not itself define any
protocol formats or mechanisms.

> Is this type of RFC indicated in the title page header?

Yes

> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up. Recent
> examples can be found in the "Action" announcements for approved
> documents. The approval announcement contains the following sections:
>
> Technical Summary:
>
> Relevant content can frequently be found in the abstract and/or
> introduction of the document. If not, this may be an indication that
> there are deficiencies in the abstract or introduction.


  This document addresses DetNet-specific security considerations from
  the perspective of both the DetNet component designer and the DetNet
  system-level designer. this document provides an
  association of threats against various use cases by industry, and
  also against the individual service properties as defined in the
  DetNet Use Cases.

  This document also addresses common DetNet security considerations
  related to the IP and MPLS data plane technologies (the first to be
  identified as supported by DetNet), thereby complementing the
  Security Considerations sections of the various DetNet Data Plane
  (and other) DetNet documents.

> Working Group Summary:
>
> Was there anything in WG process that is worth noting? For example, was
> there controversy about particular points or were there decisions where
> the consensus was particularly rough?

There was significant discussion on what should be in this document and
if it was sufficient.  In the end, the document was indirectly reviewed
by several in the security directorate, as part of their reviews of the
previously submitted (for publication) data plane document and the
general feeling was that this document was in sufficient maturity to be
submitted for publication/

> Document Quality:
>
> Are there existing implementations of the protocol? Have a significant
> number of vendors indicated their plan to implement the specification?
> Are there any reviewers that merit special mention as having done a
> thorough review, e.g., one that resulted in important changes or a
> conclusion that the document had no substantive issues? If there was a
> MIB Doctor, YANG Doctor, Media Type or other expert review, what was its
> course (briefly)? In the case of a Media Type review, on what date was
> the request posted?

The document is one of the foundation documents for other DetNet WG
activities. It notably has had contributions from end-user part of the
market.

> Personnel:
>
>  Who is the Document Shepherd?
Lou Berger

> Who is the Responsible Area Director?
Deborah Brungard

> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd. If this version of the document is not ready for
> publication, please explain why the document is being forwarded to the
> IESG.

I have reread this document as it progressed as well as in its final
form.  All significant comments have been addressed. The document is
ready for publication.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

No. 

> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that took
> place.

While this document has be read/commented on by some in the security
directorate, we certainly expect that it will receive an additional
review as part of normal IESG processing.

> (6) Describe any specific concerns or issues that the Document Shepherd
> has with this document that the Responsible Area Director and/or the
> IESG should be aware of? For example, perhaps he or she is uncomfortable
> with certain parts of the document, or has concerns whether there really
> is a need for it. In any event, if the WG has discussed those issues and
> has indicated that it still wishes to advance the document, detail those
> concerns here.

No.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why?

yes, see:
https://mailarchive.ietf.org/arch/msg/detnet/oCh4L5p5qPO26RfV7RDP_UxzRac/


> (8) Has an IPR disclosure been filed that references this document? If
> so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.

N/A.

> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others being
> silent, or does the WG as a whole understand and agree with it?

I think the document has good support from active contributors.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in separate
> email messages to the Responsible Area Director. (It should be in a
> separate email because this questionnaire is publicly available.)

No.

> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough.

Some of the informational references are to outdated versions.

> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type
> reviews.

N/A.

> (13) Have all references within this document been identified as either
> normative or informative?

Yes.

> (14) Are there normative references to documents that are not ready for
> advancement or are otherwise in an unclear state? If such normative
> references exist, what is the plan for their completion?

No.

> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.

No.

> (16) Will publication of this document change the status of any existing
> RFCs? Are those RFCs listed on the title page header, listed in the
> abstract, and discussed in the introduction? If the RFCs are not listed
> in the Abstract and Introduction, explain why, and point to the part of
> the document where the relationship of this document to the other RFCs
> is discussed. If this information is not in the document, explain why
> the WG considers it unnecessary.

No, N/A.

> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA
> registries. Confirm that any referenced IANA registries have been
> clearly identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 8126).

No requests are made in the document.

> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find useful
> in selecting the IANA Experts for these new registries.

None.

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language, such as XML code, BNF rules, MIB definitions, YANG modules,
> etc.

N/A

> (20) If the document contains a YANG module, has the module been checked
> with any of the recommended validation tools
> (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
> formatting validation? If there are any resulting errors or warnings,
> what is the justification for not fixing them at this time? Does the
> YANG module comply with the Network Management Datastore Architecture
> (NMDA) as specified in RFC8342?

There are no yang models.

IPR Call: https://mailarchive.ietf.org/arch/msg/detnet/oCh4L5p5qPO26RfV7RDP_UxzRac/

Re: [Detnet] Regarding IPR on draft-ietf-detnet-s…  Norman Finn
Re: [Detnet] Regarding IPR on draft-ietf-detnet-s…  Tal Mizrahi
Re: [Detnet] Regarding IPR on draft-ietf-detnet-s…  Balázs Varga A
Re: [Detnet] Regarding IPR on draft-ietf-detnet-s…  Grossman, Ethan A.
Re: [Detnet] Regarding IPR on draft-ietf-detnet-s…  Henrik Austad
Re: [Detnet] Regarding IPR on draft-ietf-detnet-s…  Janos Farkas
Re: [Detnet] [EXTERNAL] Regarding IPR on draft-ie…  Das, Subir

Still waiting on:

ajhacker@mistiqtech.com,  john.dowdell.ietf@gmail.com, Carsten Bormann

Request for posting confirmation emailed to previous authors: John Dowdell , Norman Finn , Subir Das , Tal Mizrahi , Andrew Hacker , Ethan Grossman , Henrik Austad

Request for posting confirmation emailed to previous authors: John Dowdell , Norman Finn , Kevin Stanton , Subir Das , Tal Mizrahi , Andrew Hacker , Ethan Grossman , Henrik Austad

Request for posting confirmation emailed to previous authors: John Dowdell , Norman Finn , Kevin Stanton , Subir Das , Tal Mizrahi , Andrew Hacker , Ethan Grossman , Henrik Austad

Request for posting confirmation emailed to previous authors: John Dowdell , Norman Finn , Tal Mizrahi , Kevin Stanton , Subir Das , detnet-chairs@ietf.org, Andrew Hacker , Ethan Grossman , Henrik Austad

Request for posting confirmation emailed to previous authors: John Dowdell , Norman Finn , Tal Mizrahi , Kevin Stanton , Subir Das , Andrew Hacker , Ethan Grossman , Henrik Austad

Request for posting confirmation emailed to previous authors: John Dowdell , Norman Finn , Tal Mizrahi , Kevin Stanton , Subir Das , Andrew Hacker , Ethan Grossman , Henrik Austad