Last Call Review of draft-ietf-sfc-proof-of-transit-08
review-ietf-sfc-proof-of-transit-08-genart-lc-bryant-2021-09-23-00

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.