Re: [ippm] John Scudder's Discuss on draft-ietf-ippm-ioam-conf-state-07: (with DISCUSS and COMMENT)

[[e-mail]]

Hi John,






Thank you for the quick reply.


Please check inline my responses.






Best Regards,


Xiao Min







Original



From: JohnScudder <[e-mail]>
To: 肖敏10093570;
Cc: The IESG <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2022年10月27日 21:55
Subject: Re: John Scudder's Discuss on draft-ietf-ippm-ioam-conf-state-07: (with DISCUSS and COMMENT)


Hi Xiao Min,
 
Some replies in-line below; I’ve snipped out agreed points that don’t need further discussion.
 
> On Oct 27, 2022, at 5:51 AM, [e-mail] wrote:
[…snip…]
> NEW:
>    There is a need to extend echo request/reply mechanisms used in IPv6
>    (including Segment Routing with IPv6 data plane (SRv6)), MPLS
>    (including Segment Routing with MPLS data plane (SR-MPLS)), Service
>    Function Chain (SFC) and Bit Index Explicit Replication (BIER)
>    environments, for use within the In situ Operations, Administration,
>    and Maintenance (IOAM) domain, allowing the IOAM encapsulating node
>    to discover the enabled IOAM capabilities of each IOAM transit and
>    IOAM decapsulating node.
>  
>    Although this document does not itself specify the necessary
>    extensions, it specifies formats and objects that can be used in such
>    specifications, and provides guidelines and requirements for their
>    development.
>  
> [XM]>>> It seems this comment is similar to that one made by Alvaro Retana. Does the abstract proposed by Alvaro work for you?
>  
> NEW Abstract:
>  
>    This document describes a generic format for use in echo
> request/reply mechanisms, which can be used within an In situ
> Operations, Administration, and Maintenance (IOAM) domain, allowing
> the IOAM encapsulating node to discover the enabled IOAM capabilities
> of each IOAM transit and IOAM decapsulating node.  The generic format
> is intended to be used with a variety of data planes such as IPv6,
> MPLS, Service Function Chain (SFC)
>    and Bit Index Explicit Replication (BIER).
 
Yes, that’s OK, although on the balance I do prefer an abstract that plainly states that follow-on documents are needed. But that’s relatively minor, Alvaro’s text works too.

[XM]>>> OK. Will use Alvaro's text.


[…snip…]
> - It wasn't clear to me from a quick perusal of RFC 9197 §4.3 whether a request
> carrying 0x0000 would elicit replies for all Namespace-IDs (since 0x0000
> matches everything) or if it would elicit replies only for capabilities that
> have no configured non-default namespace, or are explicitly configured with
> namespace 0x0000. Can you either clarify this in the text, or if you think it's
> clear from the reference, help me understand what makes it clear?
>  
> [XM]>>> As I understand it, a request carrying 0x0000 would elicit replies only for capabilities that are explicitly configured with namespace 0x0000. Also note that namespace 0x0000 is the default one, so if there is no any other namespace configured, then all capabilities configured are for namespace 0x0000 by default. Propose to add some text as below.
>  
> NEW
>  
>    An IOAM Capabilities Query carrying only the Default-Namespace-ID 0x0000 would elicit replies only for capabilities that are explicitly configured with the Default-Namespace-ID 0x0000.
 
That helps my understanding, thanks. I wonder if the new text above is exactly what you want or if it would benefit from a little more tuning. Two questions to consider —
 
- As written the statement doesn’t apply to a query carrying 0x0000 and some other value, say 0x0001. Probably you don’t want to restrict it to only singleton 0x0000 lists? Probably you could fix this by dropping the first instance of “only”, so “… carrying the Default-Namespace-ID”. (Keep the second “only” though.)
- Do you really want to restrict it to “explicitly configured”? That might create some ambiguity with regard to capabilities that are implicitly configured with 0x0000, for example, due to a system default. Perhaps drop “explicitly”?
 
So the possible revision is:
 
   An IOAM Capabilities Query carrying the Default-Namespace-ID 0x0000 would elicit replies only for capabilities that are configured with the Default-Namespace-ID 0x0000.

[XM]>>> The revision implicates that as long as an IOAM Capabilities Query carries 0x0000, whether the only one or along with other namespace-id, it would elicit replies only for capabilities that are configured with the 0x0000, however that's not the intended behavior, right?


[…snip…]
> - The specification that the payload is zero-padded to 4-octet alignment
> carries some implications. Let's explore these with an example. Suppose we want
> to signal a single Namespace-ID, 0x0001. Then presumably the payload has to be
> 0x0001 0x0000, once the mandated pad bytes are added. Is the receiver supposed
> to know that it ignores the 0x0000 value (which is otherwise the
> Default-Namespace-ID) because it comes at the end of the list, not the
> beginning as the previous paragraph required? If so, this seems worth calling
> out. If not, how is the receiver supposed to know where payload ends and
> padding begins?
>  
> [XM]>>> In your example, I believe the last 0x0000 should be treated as padding by the receiver. Do you see a need for some new text?
 
Yes I do, I think that case is too subtle to leave it to the implementor to figure out and indeed someone might misapply Postel’s principle and consume the 0x0000 anyway, absent clear direction to the contrary. Perhaps something like,
 
OLD:
   The IOAM Capabilities Query Container has a container header that is
   used to identify the type and optionally length of the container
   payload, and the container payload (List of IOAM Namespace-IDs) is
   zero-padded to align to a 4-octet boundary.
 
NEW:
   The IOAM Capabilities Query Container has a container header that is
   used to identify the type and optionally length of the container
   payload, and the container payload (List of IOAM Namespace-IDs) is
   zero-padded to align to a 4-octet boundary. Note that since the
   Default-Namespace-ID of 0x0000 is mandated to appear first in the
   list, if it appears any trailing 0x0000 octets must therefore be padding
   and MUST be disregarded.

[XM]>>> The new text you provided looks good to me.


> ### Section 3.2, container format, padding
>  
> Similar questions to those above apply to:
>  
> ```
>    The IOAM Capabilities Response Container has a container header that
>    is used to identify the type and optionally length of the container
>    payload, and the container payload (List of IOAM Capabilities
>    Objects) is zero-padded to align to a 4-octet boundary.
> ```
>  
> That is, considering you've disclaimed defining specifics about the semantics
> of the header, how is the recipient of one of these things supposed to know how
> to ignore the zero-padding?
>  
>  
>  
> I do see that all the objects you've defined in this document are a multiple of
> four bytes long (if we assume their unspecified headers are a multiple of four
> byte long, that is!) so no padding would ever be required for a payload
> consisting only of these objects, and thus my question wouldn't apply. But if
> that's the answer to my question, then the final clause I quote above (about
> zero-padding) should just be removed.
>  
> [XM]>>> Will remove the final clause you quoted above (about zero-padding).
 
OK.  
 
How problematic would it be if the header turned out not to be word-aligned? Do you need to say something about this in the spec? (This applies to everywhere you have an abstract header in the spec.)

[XM]>>> Yes, I would like to borrow your text as below.

OLD

    The IOAM Capabilities Response Container has a container header that    is used to identify the type and optionally length of the container    payload, and the container payload (List of IOAM Capabilities    Objects) is zero-padded to align to a 4-octet boundary.

NEW

    The IOAM Capabilities Response Container has a container header that    is used to identify the type and optionally length of the container    payload. The container header MUST be defined such that it falls on a four-octet   boundary.


> ### Section 3.2, object format, padding
>  
> ```
>    Similar to the container, each object has an object header that is
>    used to identify the type and length of the object payload, and the
>    object payload is zero-padded to align to a 4-octet boundary.
> ```
>  
> Similar to the above, in some cases there will be a need to know how to
> separate payload from padding. In all the objects you defined in Sections 3.2.x
> this is unnecessary (*if* you assume the unspecified header is 4-octet aligned
> itself) since you've carefully specified them so that they don't require
> padding.
>  
> It might be more straightforward to just mandate that future object
> specifications have a length that is a multiple of four octets, as all of your
> current ones do. That defers the question of what to do about variable payloads
> to the specification of the -- notional? -- object that has such a payload.
>  
> [XM]>>> Will remove the final clause you quoted above (about zero-padding). Do you see a need for some new text?
 
It comes back to the question above — how problematic is it, if something ends up not being word-aligned in the future? I suppose you wouldn’t have mandated word-alignment if you didn’t think it was important, so that implies you should say something. For example,
 
OLD:
   Similar to the container, each object has an object header that is
   used to identify the type and length of the object payload, and the
   object payload is zero-padded to align to a 4-octet boundary.
 
NEW:
   Similar to the container, each object has an object header that is
   used to identify the type and length of the object payload. The  
   object payload MUST be defined such that it falls on a four-octet
   boundary.

[XM]>>> The new text you provided looks good to me and I borrowed your text as above.


[…snip…]
> ### Section 6, integrity protection
>  
> You talk about integrity protection in passing. Let's assume a deployment
> hasn't enabled any kind of integrity protection. Have you done any analysis of
> what kind of mischief an attacker could cause by inserting incorrect
> capabilities in a forged response?
>  
> [XM]>>> Before I read your question, no :-) I think one possible mischief is that the IOAM encapsulated data packet could be dropped due to its size exceeds the path MTU, another one is that the added IOAM header could not be processed by the nodes along the path.
 
Those don’t sound too serious. Up to you whether to include that in the section, but I don’t think it would hurt.

[XM]>>> I prefer to remain the text as is. Thank you for raising that question pushing me take the possible mischiefs into account.


Thanks,
 
—John