Re: [Tsv-art] [Last-Call] Tsvart last call review of draft-ietf-mpls-sfl-framework-08

Stewart Bryant <stewart.bryant@gmail.com> Thu, 02 July 2020 14:02 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F273A0823; Thu, 2 Jul 2020 07:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.com
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 Z7LRdML5CdvZ; Thu, 2 Jul 2020 07:02:03 -0700 (PDT)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 B2C603A0821; Thu, 2 Jul 2020 07:02:02 -0700 (PDT)
Received: by mail-wm1-x334.google.com with SMTP id o8so26915794wmh.4; Thu, 02 Jul 2020 07:02:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IwX8iCVU1gOecEuvm/QHM+bhbLPdLLu24+Kbp9fDR7Y=; b=RE6zpQinGgEOAQeVNBZ5IDgc+fHuN3CV50vOGjKA4f8KL41BVh8ehJmL5FAt/157K8 FcGGHXKIOQRTlPdUlEFAjiXjJO4QTkJnhlFWQRA23AWcTjRWQgU0zAVtPg9gOVklYMS8 p5F8sQHgxMYmf9GiheiLqeHon1E/IuRQOErwuw5pZ4Y0PEg19iQzrjVaYYkAxSFREBsh Mwi3fOdmq27NK137yuc1YoPzZyMjmzZh1pZecsjsvAwtZbFpUYQ2m8BsQAZQvtjDqqV4 QwAWfVd70roKZ4saIzX+chfj9WzO18/a0XMgdEscaYSe/DKK8SVhfZBDRNYrPGMWBFIB EtZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IwX8iCVU1gOecEuvm/QHM+bhbLPdLLu24+Kbp9fDR7Y=; b=jr3oyRu+a+vqeIk3acQNwoGnMppdK8xON4Rud0THkSelfIHFpx++3Xbrw0LE95I8Y8 LJuVldrOMhQh16exVtszwvDTmMVq2ODaxV/UlhwnMj1sgtTfobOrxzFjVgNMMVZb7NMV 9wVM/nBdr0090BYyr8ylhX+Xqg/yTMy+hhfHGwbOCpOzNi+MYQd4oGYXIgnDqolselD8 uEDO5sNy41DL7YFMNl7iGOyMfB1Z+MYSB8tKqtFpEMrbGfo1YSRAORQNPOMADOam5Fz+ VxEQBKZ951TMtiI3oBpe8o2XF53RCpvINbHBe/hJ5AeFtuIjUgxrrXlGZWuFEb77Oc3U m3pg==
X-Gm-Message-State: AOAM533EJByTiAtPef+iQMaBJ62c6K7JusoQPwGASIJDGGZaZ36j4u2f SDRj6WGp0ra96YjFSAj3mQY=
X-Google-Smtp-Source: ABdhPJweL9t/f2HQLNS5Ob+gGJBCvC8PZAxWdAV7zIGk0EQsSrP0AJ1nfU/c9MDZs/DD4csyOJ6M3A==
X-Received: by 2002:a7b:c208:: with SMTP id x8mr32019785wmi.49.1593698521048; Thu, 02 Jul 2020 07:02:01 -0700 (PDT)
Received: from [192.168.178.46] ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id 133sm11490271wme.5.2020.07.02.07.02.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Jul 2020 07:02:00 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Stewart Bryant <stewart.bryant@gmail.com>
In-Reply-To: <159356228599.17610.11697654273935266920@ietfa.amsl.com>
Date: Thu, 02 Jul 2020 15:01:29 +0100
Cc: Stewart Bryant <stewart.bryant@gmail.com>, tsv-art@ietf.org, mpls <mpls@ietf.org>, draft-ietf-mpls-sfl-framework.all@ietf.org, last-call@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8AABE423-121C-4265-B3E0-FCE0AAF12C05@gmail.com>
References: <159356228599.17610.11697654273935266920@ietfa.amsl.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/SQoPF2W_AmNGFpYGhqiEoguuRwc>
Subject: Re: [Tsv-art] [Last-Call] Tsvart last call review of draft-ietf-mpls-sfl-framework-08
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jul 2020 14:02:05 -0000


> On 1 Jul 2020, at 01:11, Bernard Aboba via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Bernard Aboba
> Review result: Ready with Issues
> 
> Subject: Transport Directorate review of draft-ietf-mpls-sfl-framework
> 
> Reviewer: Bernard Aboba
> Review result: Ready with (Minor) Issues
> Document: draft-ietf-mpls-sfl-framework-08
> Reviewer: Bernard Aboba
> Review Date: 2020-06-30
> Intended Status: Informational
> 
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document's
> authors and WG to allow them to address any issues raised and also to the IETF
> discussion list for information.
> 
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-art@ietf.org if you reply to or forward this review.
> 
> Summary:
>        This document is ready for publication, but has some minor issues
>        that could be addressed.
> 
> Comments:
>        The document is short and clearly written.  While it references
>        the requirements in RFC 8372, it does not refer to them, so it's
>        hard to verify whether this document does address those
>        requirements (and how).
> 
>        Also, this document doesn't cover data collection or SFL allocation,
>        so there is quite a bit that is out of scope. This makes me wonder
>        whether an implementation of this specification could interoperate
>        with other implementations based solely on this specification. 

Dear Bernard

The intent of this document is to set out the framework in which other specific documents, which describe specific protocol actions, act.

There is a document in flight which describes the use of this method for OAM actions and a control plane. Both of this will be implementable specifications. This informational text is not intended to be directly implementable and needs other supporting text.

> 
> Major Issues:
>        No major issues found 
> 
> Minor Issues:
> 
> Section 6 Privacy Considerations
> 
> Section 3 states: 
> 
> "  There are many possible additional actions such as
>   the measurement of the number of received packets in a flow,
>   triggering IPFIX inspection, triggering other types of Deep Packet
>   Inspection, or identification of the packet source."
> 
> [BA] Based on the above statements, it would seem that this specification
> has potential uses (e.g. DPI) that have inherent privacy implications. 
> This seems to be worth mentioning.

There is privacy text in the document.

The scope of this protocol is a well managed and controlled network. If the operator were to do DPI to impose the SFL at ingress, there would be no need for them to telegraph this to the far end of the LSP when they could send that information from the ingress node.

> 
>   "Whilst the inclusion of the additional
>   granularity does allow greater insight into the flow characteristics
>   it does not specifically identify which node originated the packet
>   other than by inspection of the network at the point of ingress, or
>   inspection of the control protocol packets."
> 
> [BA] By definition, flow identities provide insight into flow characteristics.
> By correlating the flow identity with persistent identifiers such as MAC
> addresses, the flow identity can be linked to a device or user
> without needing to inspect the network at the point of ingress or to
> inspect control protocol packets. So there can be an incremental privacy
> impact, even if the flow identifier does not itself identify a
> user. 

It is unlikely that the use of this protocol would be for anything other than exceptional actions such as instrumentation. The identifier space is too small for, for example, for every flow to be marked, so I don’t think the risk is significant. If you wanted to spy on packets, you would do better to correlate with the VPN or pseudowire identity rather than this.

> 
> Section 7 Security Considerations
> 
> "The issue noted in Section 6 is a security consideration."
> 
> [BA] I don't think that the privacy issues described in Section 6 need necessarily be referenced
> in the security considerations section.  I think you can delete this sentence.
> 

Yes I will remove that reference, several people have commented.

Best regards

Stewart

> 
> 
> -- 
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call