Subject: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

From: Lars Eggert via Datatracker <[email-masked]>
Date: Fri, 06 Aug 2021 02:36:07 -0700

Lars Eggert has entered the following ballot position for
draft-ietf-6man-ipv6-alt-mark-08: 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-ipv6-alt-mark/

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

Section 2.1. , paragraph 4, discuss:
>    Therefore, the IPv6 application of the Alternate Marking Method MUST
>    NOT be deployed outside a controlled domain.

That's not what Section 6 says, which allows use outside a controlled
domain (across the Internet) if protection is applied?

Section 2.1. , paragraph 4, discuss:
>    Some scenarios may imply that the Alternate Marking Method is applied
>    outside a controlled domain, either intentionally or unintentionally,
>    but in these cases, IPsec authentication and encryption MUST be used.

How can one require use of IPsec for an unintentional use outside of a
controlled domain? If the header leaks by accident, surely it's unreasonable to
expect that IPsec had been set up to catch any and all such possible leakage?

Also (as a comment), if IPsec is required by this document, it needs to be
normatively cited.

Section 5.3.1. , paragraph 2, discuss:
>    It is important to note that if the 20 bit FlowMonID is set
>    independently and pseudo randomly there is a chance of collision.
>    Indeed, by using the well-known birthday problem in probability
>    theory, if the 20 bit FlowMonID is set independently and pseudo
>    randomly without any additional input entropy, there is a 50% chance
>    of collision for 1206 flows.  So, for more entropy, FlowMonID can
>    either be combined with other identifying flow information in a
>    packet (e.g. it is possible to consider the hashed 3-tuple Flow
>    Label, Source and Destination addresses) or the FlowMonID size could
>    be increased.

It seems odd to define a dedicated FlowMonID, but make it so short that it is
basically not usable in many realistic scenarios. If other parts of the packet
headers need to be inspected to disambiguate FlowMonID collisions, this (1)
should at least be more carefully specified in this document (since every node
will need to do it in the same way) but (2) probably argues for a much longer
FlowMonID - why not make it 64 bits or longer?

The IANA review of this document seems to not have concluded yet; I am holding
a DISCUSS for IANA until it has.

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

Section 5.1. , paragraph 4, comment:
>    issues.  Specifically, if the effects of network delay are ignored,
>    the condition to implement the methodology is that the clocks in
>    different nodes MUST be synchronized to the same clock reference with
>    an accuracy of +/- B/2 time units, where B is the fixed time duration
>    of the block.

What is a block? Do you mean a batch? I see that RFC8321 uses "block", should
this document adopt that term?

Also, how can a block (of packets) have a "fixed time duration"? Is this
supposed to mean transmission time of the block at line-rate? What about pacing?

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2.1. , paragraph 4, nit:
-    an implementation can be able to reject packets that carry Alternate
-                      ---------------
+    an implementation rejects packets that carry Alternate
+                            +

Section 3.1. , paragraph 5, nit:
-    o  Option Type: 8 bit identifier of the type of Option that needs to
-                     ^
+    o  Option Type: 8-bit identifier of the type of Option that needs to
+                     ^

Section 3.1. , paragraph 7, nit:
-    o  FlowMonID: 20 bits unsigned integer.  The FlowMon identifier is
-                    ^   -
+    o  FlowMonID: 20-bit unsigned integer.  The FlowMon identifier is
+                    ^

Section 3.1. , paragraph 7, nit:
-       picked 20 bit since it is a reasonable value and a good compromise
+       picked as 20 bit since it is a reasonable value and a good compromise
+             +++

Section 4. , paragraph 6, nit:
-    are useable when SRv6 header is present.  Because SRv6 is implemented
-          -
+    are usable when SRv6 header is present.  Because SRv6 is implemented

Section 1. , paragraph 3, nit:
> sely measure the packet loss. In a similar way the alternation of the values
>                               ^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "similarly" to avoid wordiness.

Section 1.1. , paragraph 1, nit:
> I-D.fioccola-v6ops-ipv6-alt-mark] analyzed and discussed all the available po
>                                   ^^^^^^^^
Do not mix variants of the same word ("analyze" and "analyse") within a single
text.

Section 2. , paragraph 8, nit:
> and on the nodes that support it. However it is important to mention that th
>                                   ^^^^^^^
A comma may be missing after the conjunctive/linking adverb "However".

Section 2. , paragraph 11, nit:
> intent and forwarding behaviour. Furthermore the Flow Label may be changed en
>                                  ^^^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Furthermore".

Section 2.1. , paragraph 2, nit:
> f IPsec for an unintentional use outside of a controlled domain? If the head
>                                  ^^^^^^^^^^
This phrase is redundant. Consider using "outside".

Section 3.1. , paragraph 1, nit:
> rd-highest-order bit specifies whether or not the Option Data can change en r
>                                ^^^^^^^^^^^^^^
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

Section 3.1. , paragraph 4, nit:
> ssed below, it has been picked as 20 bit since it is a reasonable value and a
>                                      ^^^
Possible agreement error. The noun "bit" seems to be countable.

Section 4. , paragraph 6, nit:
> intermediate node can read it or not but this does not affect the packet beh
>                                     ^^^^
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

Section 4. , paragraph 8, nit:
> an-hbh-processing], this means "skip if do not recognize and data do not cha
>                                      ^^
It seems that a pronoun is missing.

Section 4. , paragraph 12, nit:
> most applicable methods are reported and a new field is introduced to facili
>                                     ^^^^
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

Section 5.1. , paragraph 4, nit:
> ge the length of batches over time and and among different flows for more fle
>                                    ^^^^^^^
Possible typo: you repeated a word.

Section 5.1. , paragraph 9, nit:
> rage timestamp for each batch. In addition the information is limited to a me
>                                   ^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "addition".

Section 5.2. , paragraph 3, nit:
> the approach with single marking. Moreover the two approaches can also be com
>                                   ^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Moreover".

Section 5.2. , paragraph 7, nit:
> table in most of the applications. Indeed with 20 bits the number of combinat
>                                    ^^^^^^
A comma may be missing after the conjunctive/linking adverb "Indeed".

Section 5.3.1. , paragraph 3, nit:
> r of IPv6 packets by the source node but this must be performed in a way tha
>                                     ^^^^
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

Section 6. , paragraph 2, nit:
> privacy concerns also need to be analyzed even if the method only relies on
>                                  ^^^^^^^^
Do not mix variants of the same word ("analyze" and "analyse") within a single
text.

Section 6. , paragraph 4, nit:
>  paths. AltMark Option contains two kind of metadata: the marking bits (L and
>                                     ^^^^
Possible agreement error. The noun "kind" seems to be countable.

Section 6. , paragraph 5, nit:
> n data-plane traffic is difficult. Indeed an attacker cannot gain information
>                                    ^^^^^^
A comma may be missing after the conjunctive/linking adverb "Indeed".

Section 6. , paragraph 6, nit:
> hin the network domain. [RFC8799] analyzes and discusses the trend towards ne
>                                   ^^^^^^^^
Do not mix variants of the same word ("analyze" and "analyse") within a single
text.

Section 6. , paragraph 7, nit:
> tMark Option leaving the domain. Therefore the trusted domain is unlikely su
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Therefore".

Section 6. , paragraph 7, nit:
> ome packets might exceed the MTU. However the relative small size (48 bit in
>                                   ^^^^^^^
A comma may be missing after the conjunctive/linking adverb "However".

Section 6. , paragraph 9, nit:
>  described in this document relies on an time synchronization protocol. Thus,
>                                       ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Document references draft-peng-v6ops-hbh-04, but -05 is the latest available
revision.

Document references draft-fioccola-v6ops-ipv6-alt-mark-01, but -08 is the
latest available revision.

---

From: Giuseppe Fioccola <[email-masked]>
Date: Fri, 6 Aug 2021 15:58:13 +0000

Dear Lars,
Thank you for your review. 
Please find my replies inline tagged as [GF].

Regards,

Giuseppe

-----Original Message-----
From: Lars Eggert via Datatracker <[email-masked]> 
Sent: Friday, August 6, 2021 11:36 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

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.)

>    NOT be deployed outside a controlled domain.

That's not what Section 6 says, which allows use outside a controlled domain (across the Internet) if protection is applied?

[GF]: Maybe we should change the wording here. In general, Alternate Marking MUST be applied in a controlled domain. In specific cases (e.g. SDWAN), an enterprise user, aware of the kind of risks of this on-path telemetry technique, may still want to apply Alternate Marking for the e2e service and consequently outside a controlled domain; in this case IPsec is RECOMMENDED. To avoid misunderstanding, we could also omit this consideration and leave the only requirement of the controlled domain.

>    but in these cases, IPsec authentication and encryption MUST be used.

How can one require use of IPsec for an unintentional use outside of a controlled domain? If the header leaks by accident, surely it's unreasonable to expect that IPsec had been set up to catch any and all such possible leakage?

Also (as a comment), if IPsec is required by this document, it needs to be normatively cited.

[GF]: IPsec is not strictly required but I could add the reference. I will change the sentence and clarify that the requirement is relative to the application to a controlled domain. IPsec is just suggested for specific cases.

>    Label, Source and Destination addresses) or the FlowMonID size could

It seems odd to define a dedicated FlowMonID, but make it so short that it is basically not usable in many realistic scenarios. If other parts of the packet headers need to be inspected to disambiguate FlowMonID collisions, this (1) should at least be more carefully specified in this document (since every node will need to do it in the same way) but (2) probably argues for a much longer FlowMonID - why not make it 64 bits or longer?

The IANA review of this document seems to not have concluded yet; I am holding a DISCUSS for IANA until it has.

[GF]: It is something we can consider. Anyway we tried to find a compromise. The FlowMonID could be set in two ways: (a) by a Controller, that knows the topology and can set the value properly to avoid/minimize ambiguity, or (b) by the source node, that can set it pseudo-randomly with some chance of collision. So, we picked up 20 bit since this value implies a low rate of ambiguous FlowMonIDs that can be considered acceptable in most of the applications.

>    an accuracy of +/- B/2 time units, where B is the fixed time duration

What is a block? Do you mean a batch? I see that RFC8321 uses "block", should this document adopt that term?

Also, how can a block (of packets) have a "fixed time duration"? Is this supposed to mean transmission time of the block at line-rate? What about pacing?

[GF]: Yes we mean a batch. We have used block to be aligned with RFC 8321 but we can also replace "block" with "batch". The "fixed time duration" refers to the original marking interval at the source node. Of course it can fluctuate along the path and we have mentioned this in section 5.1 (also adding the reference to section 3.2 of RFC 8321). I can further clarify this in the next version.

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions.

[GF]: Ok I will look at them one by one and check whether the proposed changes are consistent with the text.

Section 4. , paragraph 6, nit:
-    are useable when SRv6 header is present.  Because SRv6 is implemented
-          -
+    are usable when SRv6 header is present.  Because SRv6 is 
+ implemented

> I-D.fioccola-v6ops-ipv6-alt-mark] analyzed and discussed all the available po
Do not mix variants of the same word ("analyze" and "analyse") within a single text.

> rd-highest-order bit specifies whether or not the Option Data can change en r
Consider shortening this phrase to just "whether". It is correct though if you mean "regardless of whether".

> intermediate node can read it or not but this does not affect the packet beh
Use a comma before "but" if it connects two independent clauses (unless they are closely connected and short).

> most applicable methods are reported and a new field is introduced to facili
Use a comma before "and" if it connects two independent clauses (unless they are closely connected and short).

> r of IPv6 packets by the source node but this must be performed in a way tha
Use a comma before "but" if it connects two independent clauses (unless they are closely connected and short).

> privacy concerns also need to be analyzed even if the method only relies on
Do not mix variants of the same word ("analyze" and "analyse") within a single text.

> hin the network domain. [RFC8799] analyzes and discusses the trend towards ne
Do not mix variants of the same word ("analyze" and "analyse") within a single text.

>  described in this document relies on an time synchronization protocol. Thus,
Use "a" instead of "an" if the following word doesn't start with a vowel sound, e.g. "a sentence", "a university".

Document references draft-peng-v6ops-hbh-04, but -05 is the latest available revision.

Document references draft-fioccola-v6ops-ipv6-alt-mark-01, but -08 is the latest available revision.