Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-6man-ipv6-alt-mark-06

Lars Eggert <lars@eggert.org> Fri, 06 August 2021 09:36 UTC

Return-Path: <lars@eggert.org>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5D53A2700; Fri, 6 Aug 2021 02:36:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
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 cdkCqRM_lEnT; Fri, 6 Aug 2021 02:36:41 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C53D3A270D; Fri, 6 Aug 2021 02:36:40 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:b0b1:974:c10e:6775]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id CE3F1600357; Fri, 6 Aug 2021 12:36:32 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1628242592; bh=dF5GIgcaBzzOiDC+LZlMIsnA9ZoEM7GMbyV0x/zopZ4=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=hfu5v0kwRx+J/yI3wpQbUkoRFYDbw+9XXwdDt8Zth56InbC73ahz2/lZUqfUQZHSP R3a9/Mj1bPuCSAhx4LnH2cknV1NWN+X3S4Fs1Hah02jZu0WtkBPXDIdQIlb8qtpYj5 3y5vabnBom3ua3XbrK6Ym8wB3HLOyEZ13iS+HPws=
From: Lars Eggert <lars@eggert.org>
Message-Id: <BAA46CD5-325A-4777-B950-8407781A6C35@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_BE8CA935-954E-4F66-A20A-9A0B8C83FC50"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Fri, 6 Aug 2021 12:36:29 +0300
In-Reply-To: <162306626911.23339.10034981997716573258@ietfa.amsl.com>
Cc: General Area Review Team <gen-art@ietf.org>, last-call@ietf.org, ipv6@ietf.org, draft-ietf-6man-ipv6-alt-mark.all@ietf.org
To: Stewart Bryant <stewart.bryant@gmail.com>
References: <162306626911.23339.10034981997716573258@ietfa.amsl.com>
X-MailScanner-ID: CE3F1600357.A53E1
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/vXeeFuOviCmCJKOp5casDwfCexA>
Subject: Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-6man-ipv6-alt-mark-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Aug 2021 09:36:56 -0000

Stewart, thank you for your review. I have entered a Discuss ballot for this document.

Lars


> On 2021-6-7, at 14:44, Stewart Bryant via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Stewart Bryant
> Review result: Not Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-6man-ipv6-alt-mark-06
> Reviewer: Stewart Bryant
> Review Date: 2021-06-07
> IETF LC End Date: 2021-06-15
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: Regrettably I think that this document needs significant editing
> before it can be published. The document still includes a lot of discussion
> about options that is suited to a early text proposing the concept, but THIS
> text is a standards track RFC and needs to be precise about how the idea works
> and what independent implimentors need to implement. I am concerned that there
> is insufficient text on how a measurement is set up/configured and the results
> reported. I am also concerned that the security implications are not
> sufficiently documented.
> 
> Major issues:
> 
> 2.  Alternate Marking application to IPv6
> 
>   The Alternate Marking Method requires a marking field.  As mentioned,
>   several alternatives have been analysed in
>   [I-D.fioccola-v6ops-ipv6-alt-mark] such as IPv6 Extension Headers,
>   IPv6 Address and Flow Label.
> 
>   Consequently, a robust choice is to standardize a new Hop-by-Hop or
>   Destination Option.
> SB> I-D.fioccola-v6ops-ipv6-alt-mark looks like it will always be an ID and not
> progress to RFC. Also within the scope of this standards track text
> “consequently” is quite a leap. I think that this should perhaps be SB>
> I-D.fioccola-v6ops-ipv6-alt-mark demonstrated that that a new Hop-by-Hop or a
> new Destination Option was the best approach. SB> However, if
> I-D.fioccola-v6ops-ipv6-alt-mark is not to be published, a summary of the
> analysis in section 2 of that document could usefully be incorporated in this
> memo as an appendix so it is clear why the approach was taken. SB>
> Alternatively you could perhaps include a short new section 2 summarising the
> design decision.
> 
> ==========
>   o  In case of Hop-by-Hop Option Header carrying Alternate Marking
>      bits, it is not inserted or deleted, but can be read by any node
>      along the path.  The intermediate nodes may be configured to
>      support this Option or not and the measurement can be done only
>      for the nodes configured to read the Option.  Anyway this should
>      not affect the traffic throughput on nodes that do not recognize
>      the Option, as further discussed in Section 4.
> SB> Perhaps
> "As discussed in Section 4 the presence of the hop-by-hop option should not
> affect the traffic throughput on nodes that do not recognise this option" SB>
> However I am not sure that you have demonstrated that to be correct. It will
> certainly take cycles to find the option or skip the option if another is
> present, and how do you know what the node will then do and how many cycles
> this will take?
> 
> ===========
> 
> SB> I will be interested in what the SecDir review says, but I have Privacy
> concerns ringing in my head as I read this and looking forward to the security
> section there is no mention of what is in essence a flow tracking cookie added
> at source.
> 
> SB> To some extent in Section 2.1 the authors try to mitigate this with a
> reference to "controlled domains", I think that this needs to be as strong as
> Alt Mark IPv6 MUST NOT be deployed outside a controlled domain. It may also
> need text about the need to reject Alt Mark packets entering and leaving
> domains. That said I am not sure what happens if a DO is used because a user
> wants to test their SD-WAN? Should that be allowed of depricated?
> 
> ===========
> 
>   o  FlowMonID: 20 bits unsigned integer.  The FlowMon identifier is
>      described in Section 5.3.
> 
> SB> Given that this not being put in an IPv6 flow ID and given that you are
> free to pick any length you wish, it would be helpful to know why 20 bits was
> picked as a size.
> 
> ===========
> SB> Operation in an SRv6 context is discussed rather briefly. I think there
> needs to be a more detailed definintion to ensure correct operation
> 
> ===========
> 
> 5.3.  Flow Monitoring Identification
> SB> I would have expected this earlier in the document as it sets up a lot of
> background.
> 
> ===========
> 
> 5.3.1.  Uniqueness of FlowMonID
> 
>   It is important to note that if the 20 bit FlowMonID is set
>   independently and pseudo randomly there is a chance of collision.
> SB> I am not sure the method of setting is specified.
> SB> Also 20 bits is a somewhat interesting size since it is too large for local
> lookup in an NPU, but may not be long enough to avoid collisions. Given that
> h/w is likely going to need to use one of its main lookup engines, why is a
> longer key not used?
> 
>   So, in some cases, FlowMonID could not be sufficient for uniqueness.
> 
>   In general the probability of a flow identifier uniqueness correlates
>   to the amount of entropy of the inputs.  For instance, 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 just
>   1206 flows.  For a 32 bit identifier the 50% threshold jumps to
>   77,163 flows and so on.  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.
> SB> This text is useful in a design discussion memo, but this is a standards
> track RFC it needs to be specific on the point of the size.
> 
> ==========
> 
> 5.5.  Data Collection and Calculation
> 
>   The nodes enabled to perform performance monitoring collect the value
>   of the packet counters and timestamps.  There are several
>   alternatives to implement Data Collection and Calculation, but this
>   is not specified in this document.
> SB> Since it is needed for deployment, where is it specified?
> 
> SB> Indeed I think that there needs to be a lot more text describing how the
> Flow IDs are co-ordinated along the path? Are nodes expected to know these
> a-priori or to glean them from the packets in flight. Is this a configured
> measurment or can it just start? How and to whome is the measurement data
> collected?
> 
> SB> This was thought through with RFC6374 and I wonder is some sort of
> adaptation of that would be a better approach.
> 
> ==========
> 6.  Security Considerations
> 
> SB> See earlier comments on security and the use of the option as a tracking
> cookie. This at least needs a reference to the security section of RFC 8799.
> Unlike MPLS these packets can leak onto the Internet, or may even be deployed
> on the Internet by those studying, for example, SD-WAN packet performance.
> 
> ==========
>   The privacy concerns of network measurement are limited because the
>   method only relies on information contained in the Option Header
>   without any release of user data.  Although information in the Option
>   Header is metadata that can be used to compromise the privacy of
>   users, the limited marking technique seems unlikely to substantially
>   increase the existing privacy risks from header or encapsulation
>   metadata.
> SB> One could argue that in a pervasive surveillance attack it would be easier
> to do first stage packet classification and thus reduce the work of the
> attacker.
> 
> ==========
>   The Alternate Marking application described in this document relies
>   on an time synchronization protocol.  Thus, by attacking the time
>   protocol, an attacker can potentially compromise the integrity of the
>   measurement.  A detailed discussion about the threats against time
>   protocols and how to mitigate them is presented in [RFC7384].
> 
> SB> RFC7384 seems to be assuming timing over packet. It does not seem to handle
> the local GPS case well, and I can imagine that local GPS will become rather
> common but has its own attack vectors. That said GPS attacks tend to be high
> profile and are a priority item for spectrum regulators.
> 
> ==========
> 
> Minor issues:
> 
> SB> In the section starting:
>   where:
> 
>   o  Option Type:
> 
> SB> I think this could be made a lot clearer to the reader with some examples.
> 
> Nits/editorial comments:
> 
>   This approach is compliant with [RFC8200].  The Alternate Marking
> SB> Perhaps
> The alternate marking approach specified in this memo is compliant….
> 
> ========
> 
>   o  In case of Destination Option Header carrying Alternate Marking
>      bits, it is not processed, inserted, or deleted by any node along
>      the path until the packet reaches the destination node.  Note
>      that, if there is also a Routing Header (RH), any visited
>      destination in the route list can process the Option Header.
> SB> s/the Option/the alternative marking Option/
> 
> =========
> 
> Para starting    Note that the FlowMonID is different from the Flow Label field
> of the
>   IPv6 Header ([RFC8200]).
> 
> This needs significant copy editing
> 
> =========
> 
> 3.1.  Data Fields Format
> 
>   The following figure shows the data fields format for enhanced
>   alternate marking TLV.  This AltMark data is expected to be
> SB> Shouldn’t that be *is encapsulated*
> 
> ==========
> 
>   The AltMark Option is the best way to implement the Alternate Marking
>   method and can be carried by the Hop-by-Hop Options header and the
>   Destination Options header.
> SB> it *is* carried that way.
> 
> ==========
> 
> 
> --
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call