Reviewer: Stewart Bryant Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-sfc-proof-of-transit-08 Reviewer: Stewart Bryant Review Date: 2021-09-23 IETF LC End Date: 2021-09-28 IESG Telechat date: Not scheduled for a telechat Summary: A well written document and elegant use of technology. However it seems a complicated for the case of a well controlled network (it's apparent target) and insufficient for the known operational problem of ensuring that the packet does not silently go through nodes considered to be a security risk. Major issues: Scope of use. Given that this is an SFC draft, it would be valuable if the authors made clear whether this was intended to be scoped to in network overly functions such as SFC, MSPW, DetNet, or other it is anticipated that it is of general use, such as ordinary routers and P-nodes. ========== 7.9.2. Stealth Nodes The POT approach discussed in this document is to prove that a data packet traversed a specific set of "nodes". This set could be all nodes within a path, but could also be a subset of nodes in a path. Consequently, the POT approach isn't suited to detect whether "stealth" nodes which do not participate in proof-of-transit have been inserted into a path. SB> This is a key vulnerability of this approach and does not address the sometimes expressed contractual obligation to avoid certain traffic passing through certain equipments. SB> This deficiency should be highlighted earlier in the text, for example in the introduction. SB> A mitigation that I did not see discussed is the inclusion of TTL in the check. Inclusion of the TTL would mean that a simple routing cost change or link failure to introduce a path change would not put an unfriendly node in the path without this being noticed, and would require the use of a tunnel to introduce a stealth node. ============ POT is a mechanism that is used for verifying the path through which a packet was forwarded. The security considerations of IOAM in general are discussed in [I-D.ietf-ippm-ioam-data]. Specifically, it is assumed that POT is used in a confined network domain, and SB> If you are in a confined i.e. well controlled domain, does this mechanism need to be as complicated? ========= 3.1. Basic Idea The method relies on adding POT data to all packets that traverse a path. The added POT data allows a verifying node (egress node) to check whether a packet traversed the identified set of nodes on a path correctly or not. Security mechanisms are natively built into the generation of the POT data to protect against misuse (e.g., configuration mistakes). SB> I think it would be useful to clarify what the authors mean by “proof”. There is a difference between some thing that is legally enforceable which is proof against state actors and something that is just there to catch mistakes by the operator. ====== Minor issues: None classified as minor. Nits/editorial comments: ID-Nits brings up a number of issues that should be addressed: == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? == Outdated reference: draft-ietf-anima-autonomic-control-plane has been published as RFC 8994 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) ======== The methods how traffic is identified and associated to a specific path is outside the scope of this document. SB> English issue, perhaps “methods by which" ========= Identification could be done using a filter (e.g., 5-tuple classifier), or an identifier which is already present in the packet (e.g., path or service identifier, NSH Service Path Identifier (SPI), flow-label, etc.) SB> There is text in RFC-to-be 9056 that you might consider using for identification. This text took some crafting so would be worth looking at. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
