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

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Fri, 06 August 2021 15:58 UTC

Return-Path: <giuseppe.fioccola@huawei.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3B13A3430; Fri, 6 Aug 2021 08:58:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yer7AerUyqLy; Fri, 6 Aug 2021 08:58:19 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9A3D3A342E; Fri, 6 Aug 2021 08:58:18 -0700 (PDT)
Received: from fraeml712-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Gh99X56k4z6GFhc; Fri, 6 Aug 2021 23:57:52 +0800 (CST)
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml712-chm.china.huawei.com (10.206.15.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 6 Aug 2021 17:58:14 +0200
Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2176.012; Fri, 6 Aug 2021 17:58:14 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Lars Eggert <lars@eggert.org>, The IESG <iesg@ietf.org>
CC: "draft-ietf-6man-ipv6-alt-mark@ietf.org" <draft-ietf-6man-ipv6-alt-mark@ietf.org>, "6man-chairs@ietf.org" <6man-chairs@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, "bob.hinden@gmail.com" <bob.hinden@gmail.com>, "otroan@employees.org" <otroan@employees.org>
Subject: RE: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)
Thread-Topic: Lars Eggert's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)
Thread-Index: AQHXiqaCe4LS65IPoke4Ve63Qoanj6tmiMhA
Date: Fri, 6 Aug 2021 15:58:13 +0000
Message-ID: <cd5fb12351b74fa7a67a577994d73fb3@huawei.com>
References: <162824256748.9012.15703111505505730185@ietfa.amsl.com>
In-Reply-To: <162824256748.9012.15703111505505730185@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.81.184]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/k2cY0mSAelUnRUUY2oYnK4j10vs>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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 15:58:24 -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 <noreply@ietf.org> 
Sent: Friday, August 6, 2021 11:36 AM
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)

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?

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

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.

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

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.

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

----------------------------------------------------------------------
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?

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