John Scudder's Discuss on draft-ietf-6man-spring-srv6-oam-11: (with DISCUSS and COMMENT)

[John Scudder via Datatracker <[e-mail]>]

John Scudder has entered the following ballot position for
draft-ietf-6man-spring-srv6-oam-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-spring-srv6-oam/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I can't get past the feeling this document is really two different documents
mashed together. One is a Standards Track, 6man document, that defines the
O-flag. All the meat of that document is in §2.1 and §2.2, it would make a
nice, compact, readable 3 or 4 page RFC (maybe a little more once all the
boilerplate was in). The other is an Informational, SPRING document, that talks
about use cases at some length. It seems both cruel and counterproductive to
force SRv6 implementors who are implementing the O-flag to read through the
entire balance of the document just to be sure they haven't missed something
important. Remember these documents will live a long time, and it seems
irresponsible to clutter the essential document set with inessential use cases.

My suggestion is to split the document as outlined above.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to Stig Venaas for the Routing Directorate review.

I support Roman's discuss position.

1. The Security Directorate review
(https://mailarchive.ietf.org/arch/msg/last-call/alEuF06kwZosmLsX5FkiBVwtG4k/)
raises a concern about privacy that hasn't been responded to, either in email
or in the draft. The review says:

   ```
      This draft defines a flag in the Segment Routing Header that when
   set will result a copy of the packet being made and forwarded for
   "telemetry data collection and export." That has tremendous security
   and privacy implications that are not mentioned at all in the Security
   Considerations. The Security Considerations just say that there's
   nothing here beyond those described in <list of other RFCs>. I don't
   think that's the case.

      Maybe I'm completely missing something but this sounds to me like
   it enables what we used to call "service spy mode" on a router-- take
   a flow and fork a copy off to someone else. I think there needs to be
   a lot more discussion of the implications of this.
   ```

   While the revision of the Security Considerations section may be sufficient
   to address the "tremendous security... implications" the reviewer raises, it
   does nothing to address the privacy question. The reviewer has raised a
   serious question and deserves a serious reply to it.

2. The examples introduced in §1.3 and used throughout use the problematic
convention of distinguishing unspecified portions of the IPv6 addresses with
capital letters (only), as in 2001:db8::A:k::/128 (which also has an extra ::
in it, by the way). It seems self-evidently a bad idea to use valid hexadecimal
characters for this purpose. Please, where you don't intend to provide a
literal hex digit, use a value not in the set a-f,A-F. The cited example could
be rewritten as 2001:db8:X:k::/128, for example.

   Alternately, since these are examples, shown in an example topology, it's
   not clear to me why you couldn't simply write them out fully in real hex.

3. You use RFC 2119 terminology incorrectly many places in the document. Recall
that RFC 2119 defines SHOULD as:

   ```
   3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
      may exist valid reasons in particular circumstances to ignore a
      particular item, but the full implications must be understood and
      carefully weighed before choosing a different course.
   ```

   I generally use the rule of thumb that a SHOULD is almost a MUST. Here are
   the places you've used SHOULD:

   ```
         Ref1: An implementation SHOULD copy and record the timestamp as
         soon as possible during packet processing. Timestamp or any other
         metadata is not
         carried in the packet forwarded to the next hop.
   ```

   Can you suggest a "particular circumstance" in which it would be OK for an
   implementor to NOT copy and record the timestamp "as soon as possible"? It
   seems as though "as soon as possible" is already a near-infinite amount of
   rope to allow the implementor to do anything they want, do you really need
   to soften it further with SHOULD? I would say this should be MUST, or give
   it up and make it "should" in lower-case.

   ```
      If the telemetry data from the ultimate segment in the segment-list
      is required, a penultimate segment SHOULD NOT be a Penultimate
      Segment Pop (PSP) SID.  When the penultimate segment is a PSP SID,
      the SRH will be removed and the O-flag will not be processed at the
      ultimate segment.
   ```

   Since you are stating a law of physics here (well, figuratively) the SHOULD
   NOT seems especially inapt. If I've understand the document correctly, if
   the penultimate SID is a PSP SID then this scenario just won't work. So
   that's not SHOULD NOT, it's either MUST NOT or more appropriately, "must
   not" or "can't".

   ```
      The processing node SHOULD rate-limit the number of packets punted to
      the OAM process to a configurable rate.  This is to avoid hitting any
      performance impact on the OAM and the telemetry collection processes.
      Failure in implementing the rate limit can lead to a denial-of-
      service attack, as detailed in Section 5.
   ```

   This is a semi-legitimate SHOULD -- except, what is the "particular
   circumstance" in which it would be OK for an implementor to NOT rate-limit?
   Either state it (or at least provide some hints) or make this a MUST. (I
   note the Routing Directorate reviewer also asked about this and received no
   answer.)

   ```
      The OAM process is expected to be located on the routing node
      processing the packet.  Although the specification of the OAM process
      or the external controller operations are beyond the scope of this
      document, the OAM process SHOULD NOT be topologically distant from
      the routing node, as this is likely to create significant security
      and congestion issues.
   ```

   I have no problem with this one :-o.

   ```
                                          To exercise the behavior of a
      target SID, the OAM operation SHOULD construct the probe in a manner
      similar to a data packet that exercises the SID behavior, i.e. to
      include that SID as a transit SID in either an SRH or IPv6 DA of an
      outer IPv6 header or as appropriate based on the definition of the
      SID behavior.
   ```

   Again, is there a "particular circumstance" in which the OAM operation can
   "exercise the behavior of a target SID" without doing this? If not, it's a
   MUST or (probably better) a "should".

4. In Section 2.1.1:

   ```
      The OAM process MUST NOT process the copy of the packet or respond to
      any upper-layer header (like ICMP, UDP, etc.) payload to prevent
      multiple evaluations of the datagram.
   ```

   "Process" is a very general term, taken literally this means the OAM process
   must not do anything at all with the copy it's given. Please be more
   specific about what you mean. I'd offer text if I had a good guess as to
   your intent, but I don't.

5. General comment, "classic IPv6". I find the recurrent use of the term
"classic IPv6" along with "classic ping", "classic traceroute", etc, somehow
jarring. We aren't marketing soft drinks! In most places you've used "classic"
you could either provide no adjective at all (as with ping and traceroute) or
replace with "SRv6-incapable". In some cases, the dichotomy isn't even needed,
as in

   ```
      The existing mechanism to perform the reachability checks, along the  
      shortest path, continues to work without any modification.  The  
      initiator may be an SRv6 node or a classic IPv6 node.  Similarly, the  
      egress or transit may be an SRv6-capable node or a classic IPv6 node.
   ```

   The last sentence could easily be rewritten something like  “Any IPv6 node
   can initiate, transit, and egress a ping packet.” Similarly,

   ```
      Similarly, the egress node (IPv6 classic or SRv6-capable) does not
   ```

   could simply omit the parenthetical.

6. Nit:

   ```
      o  Node N1 initiates a traceroute probe packet with a monotonically     
      increasing value of hop count and SRH as follows (2001:db8:A:1::,
   ```

   "Monotonic" doesn't mean "increasing by 1 each time", which is what you mean
   here. There are an infinite number of valid monotonic progressions that
   wouldn't work for traceroute.

7. Please define "USP" before use. You should probably just put "USP" and "PSP"
in §1.2.

8. Nit:

   ```
      In the reference topology in Figure 1, N100 uses an IGP protocol like  
      OSPF or ISIS to get the topology view within the IGP domain.  N100
   ```

   That should be "IS-IS" (with hyphen).

9. In your Security Considerations you say

   ```
      This document does not define any new protocol extensions and relies   on
      existing procedures defined for ICMPv6.
   ```

   Surely the O-flag, which you define, is a protocol extension.