Hi Brian, Happy New Year! Thanks a lot for your review - and sorry for the delay. We've just posted a new revision https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-deployment-04.txt which is to address your comments. Please see inline. > -----Original Message----- > From: Brian Weis via Datatracker <noreply@xxxxxxxx> > Sent: Wednesday, 16 November 2022 00:19 > To: secdir@xxxxxxxx > Cc: draft-ietf-ippm-ioam-deployment.all@xxxxxxxx; ippm@xxxxxxxx; last- > call@xxxxxxxx > Subject: Secdir last call review of draft-ietf-ippm-ioam-deployment-02 > > Reviewer: Brian Weis > Review result: Has Nits > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area directors. > Document editors and WG chairs should treat these comments just like any > other last call comments. > > This document declares itself to be a deployment guide for In-situ OAM (IOAM). > It provides an overview of the different models that IOAM can have (e.g., per- > hop tracing), the IOAM protocol encapsulations that are in development, and > deployment considerations. It is well written, providing a good overview to the > use of IOAM. > > The Security Considerations section is well-written, but I have some suggestions > on how to more clearly state the threats to IOAM. > > 1. While there is mention of integrity for the Proof-of-transit option data, there > is no mention of generally needing to protect IOAM data for integrity within an > OAM domain. I understand that this IOAM deployment document can specify no > particular method, and I see that the Security Requirements of RFC 9197 does > make some more specific statements about integrity protection at the protocol > level. But it would be good here to state that in some deployments it is > important for an IOAM transit node and IAOM decapsulating node to know that > the data it received hadn’t been tampered with, and that in those cases the > IOAM data should be integrity protected. ...FB: Good point. In particular given that we have a dedicated draft that discusses the integrity of IOAM data fields. I've expanded the section about integrity protection and added I-D.ietf-ippm-ioam-data-integrity as a solution approach. Even though IOAM focused on limited domains [RFC8799], there might be deployments for which it is important for IOAM transit nodes and IOAM decapsulating nodes to know that the data received hadn't been tampered with. In those cases, the IOAM data should be integrity protected. In addition, Since IOAM options may include timestamps, if network devices use synchronization protocols then any attack on the time protocol [RFC7384] can compromise the integrity of the timestamp- related data fields. Synchronization attacks can be mitigated by combining a secured time distribution scheme, e.g., [RFC8915], and by using redundant clock sources [RFC5905] and/or redundant network paths for the time distribution protocol [RFC8039]. Integrity protection of IOAM data fields is described in [I-D.ietf-ippm-ioam-data-integrity]. > > 2. Security Considerations says > > “… in order to limit the scope of threats to within the > current network domain the network operator is expected to enforce > policies that prevent IOAM traffic from leaking outside of the > IOAM domain, and prevent IOAM data from outside the domain to > be processed and used within the domain. “ > > Filtering IOAM traffic at the edge of a domain is important. But I suggest that > the text highlight the threats a bit more strongly. > There are two issues mentioned here. > > a. “policies that prevent IOAM traffic from leaking outside of the IOAM > domain”. While there may be little or no threat to the leaking of timestamps and > other network data, there could be actual privacy issues for an IOAM > encapsulating node that is a home gateway in an operator’s network. A home > gateway is often identified with an individual, and revealing IOAM data such as > “IOAM node identifier” > and especially geo-location information outside of the domain could be > catastrophic for that user. If this threat could be incorporated into that sentence > somehow, it would be stronger. > > b. “prevent IOAM data from outside the domain to be processed and used within > the domain”. This data “processed and used within the domain” could be just > bad data where a device outside the domain is accidentally leaking into the > domain. But it could also be an agent introducing IOAM data from outside the > domain in an effort to attack the system. Perhaps this could be worded “prevent > an attacker from introducing malicious or false IOAM data to be processed and > used within the domain”. ...FB: Thanks a lot. I've followed your suggestion and also include the scenario of the home gateway: Notably, IOAM is expected to be deployed in limited network domains ([RFC8799]), thus confining the potential attack vectors to within the limited domain. Indeed, in order to limit the scope of threats to within the current network domain the network operator is expected to enforce policies that prevent IOAM traffic from leaking outside the IOAM domain, and prevent an attacker from introducing malicious or false IOAM data to be processed and used within the IOAM domain. IOAM data leakage could lead to privacy issues. Consider an IOAM encapsulating node that is a home gateway in an operator's network. A home gateway is often identified with an individual, and revealing IOAM data such as "IOAM node identifier" or geolocation information outside of the limited domain could be harmful for that user. Note that the Direct Export mode [RFC9326] can mitigate the potential threat of IOAM data leaking through data packets. > > 3. Similarly, Security Considerations also says: > > “… deployments that are not confined to a single LAN, but span > multiple inter-connected sites (for example, using an overlay > network), the inter-site links can be secured (e.g., by IPsec) > in order to avoid external eavesdropping.” > > This is a good advice, but the wording “can be secured” is rather weak. > Considering again the privacy consideration and desire for accurate data > mentioned above, this should at least say “are expected to be secured” rather > than “can be secured. Indeed, I wish that formal requirements language could > be used here but as an Informational document I’m not sure if that would be > appropriate. > > Also, a better ending to that sentence would be something like “in order to > avoid external eavesdropping and introduction of malicious or false data”. ...FB: Great suggestion. The sentence now reads: However, in deployments that are not confined to a single LAN, but span multiple interconnected sites (for example, using an overlay network), the inter-site links are expected to be secured (e.g., by IPsec) in order to avoid external eavesdropping and introduction of malicious or false data. Thanks again for your review. Cheers, Frank > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
