Subject: [Detnet] DetNet Security Consideration: OAM

From: "Grossman, Ethan A." <[email-masked]>
Date: Thu, 23 Aug 2018 18:42:47 +0000

Hi All,
Recently it was pointed out that bandwidth occupied by OAM packets added to a DetNet flow have to be accounted for in the bandwidth reservation for that flow. This made me wonder whether there were any DetNet-specific security considerations associated with OAM traffic. As I understand it based on the input I have received so far, there is nothing there that we have to consider, except to say something like "We have considered the matter and found that there are no DetNet-specific security considerations related to OAM traffic". The rationale for this is that the OAM traffic is either:
1) Generated by the network itself, and is thus trusted, because if you can't trust the network you have much worse problems. The additional bandwidth required for such packets is added by the network,  presumably transparent to the customer.
Or
2) Generated by the customer, and is thus the customer's responsibility. That is, it is our job to deliver the customer's packets with the given service level, and OAM packets are no different to us than any other data the customer is reserving bandwidth for and transmitting.

I expect to put some text into the Security draft pretty much along those lines. Can anyone think of anything I might have not taken into account? Also any further statements of confirmation that this makes sense would be appreciated.
Thanks,
Ethan.

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 23 Aug 2018 13:31:05 -0700

Hi Ethan,
thank you for the thorough analysis of the OAM in DetNet domain specifics.
I think that the proposed text is very good. I have a few comments,
questions that you can find in-line under tag GIM>>.

Regards,
Greg

On Thu, Aug 23, 2018 at 11:42 AM, Grossman, Ethan A. <[email-masked]>
wrote:

> Hi All,
>
> Recently it was pointed out that bandwidth occupied by OAM packets added
> to a DetNet flow have to be accounted for in the bandwidth reservation for
> that flow. This made me wonder whether there were any DetNet-specific
> security considerations associated with OAM traffic. As I understand it
> based on the input I have received so far, there is nothing there that we
> have to consider, except to say something like “We have considered the
> matter and found that there are no DetNet-specific security considerations
> related to OAM traffic”. The rationale for this is that the OAM traffic is
> either:
>
> 1) Generated by the network itself, and is thus trusted, because if you
> can’t trust the network you have much worse problems. The additional
> bandwidth required for such packets is added by the network,  presumably
> transparent to the customer.
>
GIM>> I think that assumtion that any network is a priori secure and thus
is trusted domain is not the one we use. Unless, of course, this is the
upfront requirement, i.e., the DetNet domain must be secure, protected.
Though for industrial applications it may be hard to comply with such
requirement because nodes may be easily accessible, perhaps taken over,
used to launch an attack.

> Or
>
> 2) Generated by the customer, and is thus the customer’s responsibility.
> That is, it is our job to deliver the customer’s packets with the given
> service level, and OAM packets are no different to us than any other data
> the customer is reserving bandwidth for and transmitting.
>
GIM>> We refer to DetNet Service OAM (to extend, do we differentiate DetNet
Transport OAM and Service OAM functionality? Perhaps separate thread to
discuss) or e2e Service OAM? In the former case, I believe, it is still the
DetNet OAM. If the latter, then for DetNEt service OAM packet are
indistinguishable from the data packets.

>
>
> I expect to put some text into the Security draft pretty much along those
> lines. Can anyone think of anything I might have not taken into account?
> Also any further statements of confirmation that this makes sense would be
> appreciated.
>
> Thanks,
>
> Ethan.
>
>
>
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet
>
>