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

Lars Eggert via Datatracker <noreply@ietf.org> Fri, 06 August 2021 09:36 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D61B3A26C2; Fri, 6 Aug 2021 02:36:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Lars Eggert via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6man-ipv6-alt-mark@ietf.org, 6man-chairs@ietf.org, ipv6@ietf.org, bob.hinden@gmail.com, otroan@employees.org, otroan@employees.org
Subject: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 7.35.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Lars Eggert <lars@eggert.org>
Message-ID: <162824256748.9012.15703111505505730185@ietfa.amsl.com>
Date: Fri, 06 Aug 2021 02:36:07 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/fRIfba84x8CA2tjOCfYqinFaz9s>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Aug 2021 09:36:08 -0000

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.