Re: [ippm] John Scudder's No Objection on draft-ietf-ippm-ioam-flags-10: (with COMMENT)

[Greg Mirsky <[e-mail]>]

Hi John, Authors, et al.,
I apologize if using this thread to ask my question is not the most
appropriate list of addressees.
After our discussion of the Loopback flag, I am still left with uncertainty
about how a looped packet is encapsulated. LSP Ping, for example, has
default encapsulation of Echo response and, in addition, means to request
the use of another path from a list of options. Or, following how IOAM is
specified for IPv6, NSH, and MPLS, will this document be complemented by
encapsulation-specific documents?

Regards,
Greg

On Thu, Aug 18, 2022 at 12:08 PM John Scudder via Datatracker <
[e-mail]> wrote:

> John Scudder has entered the following ballot position for
> draft-ietf-ippm-ioam-flags-10: No Objection
>
> 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/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks for addressing my DISCUSS and other comments, LGTM.
>
> Previous DISCUSS for posterity:
>
> Thanks for this document. I have one issue I'd like to be sure we clear up.
>
> 1. In §4.1.1,
>
>    The loopback flag MUST NOT be set if it is not guaranteed that there
>    is a return path from each of the IOAM transit and IOAM decapsulating
>    nodes,
>
> This is heartwarming but I can’t see how you could guarantee this property
> at
> all times in any network using dynamic routing or even subject to dynamic
> conditions (and that would be all networks), and for that matter I’m not
> sure
> how to write code to even determine this in any general way. Is it your
> intention that this MUST NOT is directed to the operator and not to the
> code
> implementor? Or perhaps is it for very small values of “guarantee”? That
> is, is
> this an aspirational MUST and not a MUST MUST?
>
> In general it's a little problematic when we use RFC 2119 keywords in a
> protocol document, to express desires about how a protocol's operator
> should
> deploy it. They are at their best when used to express requirements for
> how a
> coder should implement the protocol. Please consider creating an
> operational
> considerations section, and grouping operational requirements and advice
> there,
> at least in that case it becomes clear to whom the RFC 2119 keywords are
> speaking.
>
> Alternately, please qualify the keywords appropriately in-line, e.g. in the
> above text you could say something like
>
>    The domain MUST be configured such that there is expected to be a return
>    path from each of the IOAM transit and IOAM decapsulating nodes; if this
>    expectation does not apply then configuration MUST NOT enable the
> loopback
>    flag to be set,
>
> To me it seems as though it might be less painful to group these into an
> operational considerations section, but whatever works for you, as long as
> it's
> clear.
>
> I did a cursory check over the document with this in mind, the other place
> I
> identified what looks like operational guidance to me is also in §4.1.1,
> the
> paragraph about how you "SHOULD NOT exceed 1/N of the interface capacity".
> At
> first blush that looks like something that could be computed automatically
> by
> inspection of the router's hardware, but by the time we get to the end of
> the
> paragraph we see that "prior knowledge about the network topology or size"
> is
> needed, so it must really be operational guidance. (Possibly this applies
> to
> the 1/N paragraphs in §4.2 and §5 also, although it's less clearly the
> case.)
>
> COMMENTs:
>
> 2. The document cites RFCs 7014 and 5475 normatively. They don't seem
> normative
> to me, they seem informative.
>
> 3. In §4.2,
>
>                                               The L-bit MUST be cleared
>    in the copy of the packet that a node sends back towards the source.
>
> This makes me wonder, does the looped back packet inherit the IP TTL/hop
> limit
> of the parent packet? The description of it as a “copy” makes me think it
> does.
> Should this be explicit?
>
> NITS:
>
> 4. In §5,
>
>    This draft focuses on three possible use cases of active measurement
>
> Should be "this document focuses".
>
> 5. Again in §5,
>
>                                                               A selected
>       data packet that is replicated, and its (possibly truncated) copy
>       is forwarded with one or more IOAM options, while the original
>       packet is forwarded normally, without IOAM options.
>
> I think you need to delete the "that" from the first clause?
>
> 6. And once again in §5,
>
>    o  IOAM active measurement using replicated data packets: probe
>       packets are created by the encapsulating node by selecting some or
>       all of the en route data packets and replicating them.
>
> The 1/N requirement calls into question "or all" above, unless N=1,
> something
> you strongly discourage. Although you don't technically *forbid* N=1, I
> think
> the inclusion of "or all" creates confusion and you could and should leave
> it
> out while still not technically forbidding N=1.
>
> 7. In §8,
>
>                                                         The attacker can
>       potentially leverage the Loopback flag for a Distributed Denial of
>       Service (DDoS) attack, as multiple devices send looped-back copies
>       of a packet to a single source.
>
> The use of "source" is odd here. By the nature of an attack, the
> looped-back
> copies wouldn't be targeted at the actual source of the packets. Possibly
> "target" or even "victim"?
>
>
>
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm
>