Re: [Detnet] Alissa Cooper's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)

János Farkas <janos.farkas@ericsson.com> Mon, 06 May 2019 14:19 UTC

Return-Path: <Janos.Farkas@ericsson.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECF6120052 for <detnet@ietfa.amsl.com>; Mon, 6 May 2019 07:19:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.309
X-Spam-Level:
X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 j5tK10F57ZTa for <detnet@ietfa.amsl.com>; Mon, 6 May 2019 07:19:26 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E65120019 for <detnet@ietf.org>; Mon, 6 May 2019 07:19:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1557152362; x=1559744362; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Q56A+GCDAQZANDDIalvMeUZsuJudEv9xuJE7NhCCClk=; b=Mi9CQxkHgDDFKQAUcyvKb1Zpx9kz1/SOh/+cKm83auU9UWS21RaGhsEYD/DlrRbY 42E1MvKXcnZ3y4O65edkEpmIM/syr9yYEBFQbyRaNy63YB9VB2Op+29OnUzwT1xc D4MdSIMK62zJahzlwtjqUGFNhgSk5NwabB2my1peowk=;
X-AuditID: c1b4fb30-6ddff70000001814-8c-5cd0426a98da
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F5.B9.06164.A6240DC5; Mon, 6 May 2019 16:19:22 +0200 (CEST)
Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 6 May 2019 16:19:22 +0200
Received: from [131.160.180.161] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.193) with Microsoft SMTP Server id 15.1.1713.5 via Frontend Transport; Mon, 6 May 2019 16:19:22 +0200
From: János Farkas <janos.farkas@ericsson.com>
To: Alissa Cooper <alissa@cooperw.in>
CC: "Black, David" <David.Black@dell.com>, "draft-ietf-detnet-architecture@ietf.org" <draft-ietf-detnet-architecture@ietf.org>, "detnet@ietf.org" <detnet@ietf.org>, Lou Berger <lberger@labn.net>, IESG <iesg@ietf.org>, "detnet-chairs@ietf.org" <detnet-chairs@ietf.org>
References: <155067447797.31337.768983002923056061.idtracker@ietfa.amsl.com> <40b28261-5f04-7fcd-4f4f-ce243f32a808@labn.net> <1AA376D8-DE94-4FAF-B9D2-CC4E155CEC85@cooperw.in> <ec41b988-8f3c-4ae0-fc65-1269bf33f93e@labn.net> <b1c6345f-d3f1-735c-04cd-81c5a405ef11@ericsson.com> <0f7e2d9a-bf74-b5ea-6898-29ad2129a0c0@ericsson.com> <CCCB305C-257F-4436-8C6C-CAEBD2137B9D@cooperw.in> <ddfc0ddb-3ac6-d4dc-da6e-8c9889dd77c4@ericsson.com> <BEAECAD3-DA6B-4858-97C3-6C05264761E0@cooperw.in> <CE03DB3D7B45C245BCA0D2432779493630516479@MX307CL04.corp.emc.com> <fc9b75ee-8768-42aa-b322-b085985e265e@ericsson.com>
Message-ID: <3dc108b6-81d7-a6ea-730f-051d959234e3@ericsson.com>
Date: Mon, 06 May 2019 16:19:21 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <fc9b75ee-8768-42aa-b322-b085985e265e@ericsson.com>
Content-Type: multipart/alternative; boundary="------------05802FDD21A03536DC951682"
Content-Language: en-US
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyM2J7uW6W04UYg+7HlhbTz/xltPg4azGL xbX+HywWvz/NZrH48G0mi8WMPxOZLTqa37I4sHt8efKSyWPSzBnMHkuW/GTy+LCpmS2AJYrL JiU1J7MstUjfLoErY8LmJvaCw3OYK7Y+vcfewHjjKmMXIweHhICJxLuukC5GLg4hgaOMEsf2 tLNAOF8ZJY4uecwMl/n9+DhTFyMnh7BAgUT/heXMIDabgL3E3UsbwGwRAVWJq8d+sIE0MAtM ZpL42ngMatQLFok3C9awgFTxAnVsfvqOHcRmEVCR2N3SwQpiiwrESny6spgZokZQ4uTMJ2D1 nAIOEvPmrGYDuZVZIExi2hVNkDCzgLjErSfzwQ4SElCT+PT2IfsERsFZSLpnIXTMQtIBYVtI zJx/nhHClpdo3jqbGcLWkGidM5cdWXwBI/sqRtHi1OKk3HQjI73Uoszk4uL8PL281JJNjMDY Orjlt8EOxpfPHQ8xCnAwKvHwMhheiBFiTSwrrsw9xCjBwawkwpv47FyMEG9KYmVValF+fFFp TmrxIUZpDhYlcd7o1XtihATSE0tSs1NTC1KLYLJMHJxSDYxi031Du3cd6ZSdZ3hrQ9+vq6ee /Djq9OxVxdavrnN3FrDffDnJTfLVH9mZr2+mdxw8ydz0SNkjQuKky/3cOyfv8VxyEtINNZ1o VrdowQVHiWeXett6LwdN5iuwW7Z2Z2DNzY8TTle/a2SvLth9mSFm01zXQhlZhcLGzO/OMyXN X9def9necuCBEktxRqKhFnNRcSIAHQDlNKkCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/V2zVtXUUCXWrr2nUDs60dpfdzcE>
Subject: Re: [Detnet] Alissa Cooper's Discuss on draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 May 2019 14:19:29 -0000

Hi Alissa,

Revision 13 of the draft implements the change in Section 6 as you 
suggested: 
https://tools.ietf.org/html/draft-ietf-detnet-architecture-13#section-6, 
https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-architecture-13.

Thank you,
Janos


On 4/24/2019 8:25 PM, János Farkas wrote:
> Hi Alissa,
>
> Thank you for the clarification.
> I agree with the change you are suggesting.
> I propose to make the change.
>
> At this stage, I suggest to avoid any further change that is not 
> necessary.
>
> Thank you!
> Janos
>
>
> On 4/18/2019 6:52 PM, Black, David wrote:
>>
>> +1 on Alissa’s near-final comment:
>>
>> > […] the architecture does not actually forbid the possibility of 
>> adding additional information into DetNet packets that could be used 
>> as vectors for tracking/correlation.
>>
>> My understanding is that this is allowed by the DetNet architecture 
>> even though none of the data plane designs have done so to date.  In 
>> particular, I’ve seen some prior discussion of using DSCPs for to 
>> identify DetNet traffic, even though that approach is not currently 
>> being pursued.
>>
>> Thanks, --David
>>
>> *From:* detnet <detnet-bounces@ietf.org> *On Behalf Of *Alissa Cooper
>> *Sent:* Wednesday, April 17, 2019 9:34 AM
>> *To:* János Farkas
>> *Cc:* draft-ietf-detnet-architecture@ietf.org; detnet@ietf.org; Lou 
>> Berger; IESG; detnet-chairs@ietf.org
>> *Subject:* Re: [Detnet] Alissa Cooper's Discuss on 
>> draft-ietf-detnet-architecture-11: (with DISCUSS and COMMENT)
>>
>> [EXTERNAL EMAIL]
>>
>> Hi János,
>>
>>
>>
>>     On Apr 15, 2019, at 5:08 PM, János Farkas
>>     <janos.farkas@ericsson.com <mailto:janos.farkas@ericsson.com>> wrote:
>>
>>     Hi Alissa,
>>
>>     Please see in-line.
>>
>>     On 4/12/2019 7:08 PM, Alissa Cooper wrote:
>>
>>         Hi János,
>>
>>
>>
>>             On Mar 25, 2019, at 12:16 PM, János Farkas
>>             <janos.farkas@ericsson.com
>>             <mailto:janos.farkas@ericsson.com>> wrote:
>>
>>             Hi Alissa,
>>
>>             We believe that we have addressed your comments in the
>>             most recent revision:
>>             https://tools.ietf.org/html/draft-ietf-detnet-architecture-12.
>>             (https://mailarchive.ietf.org/arch/msg/detnet/utVL9ZVGcOeGtRIASRFx5WT_ErM)
>>
>>             Please let us know what else you would like to see done
>>             before you clear your DISCUSS.
>>
>>             I/we would be happy to meet with you this week if there
>>             is anything you would like to discuss.
>>
>>             Regards,
>>             Janos
>>
>>             On 2/26/2019 2:20 PM, János Farkas wrote:
>>
>>                 Hi Alissa,
>>
>>                 Thank you for your review!
>>
>>                 We can replace
>>                 "DetNet is provides a Quality of Service (QoS), and
>>                 as such, does not
>>                    directly raise any new privacy considerations."
>>                 with
>>                 "DetNet provides a Quality of Service (QoS), and as
>>                 such, is not expected to
>>                    directly raise any new privacy considerations.”
>>
>>         I don’t understand why this is not expected. From what I can
>>         tell, the architecture allows for the use off domain- or
>>         app-flow-specific IDs. These seem like a new potential vector
>>         for tracking, and one that not every QoS architecture requires.
>>
>>     As far as I understood from below, you were happy with the change
>>     to "is not expected”.
>>
>> “Combined with the above removals” (about flow IDs and OAM) is what I 
>> said. Either the architecture allows for these things, in which case 
>> one might expect them, or it doesn’t.
>>
>>
>>
>>
>>     Combined that with this discussion on the related text:
>>     https://mailarchive.ietf.org/arch/msg/detnet/-L_wsGPMqNEOtPMgsGYaJ30nFXk
>>
>>     We came to the current text:
>>        DetNet provides a Quality of Service (QoS), and as such, is not
>>        expected to directly raise any new privacy considerations, the
>>        generic considerations for such mechanisms apply.  In particular,
>>        such markings allow for an attacker to correlate flows or to
>>     select
>>        particular types of flow for more detailed inspection.
>>
>>
>>     Flow ID and associated QoS is not a new concept introduced by
>>     DetNet; therefore, does not expected to raise new concerns.
>>
>>     What specific further changes do you suggest to this text?
>>
>> Given your exchange with Benjamin and the email today from Stewart, I 
>> would suggest:
>>
>> DetNet provides a Quality of Service (QoS) mechanism, and the generic
>>
>>    considerations for such mechanisms apply.  In particular, such 
>> markings
>>
>>    allow for an attacker to correlate flows or to select particular types
>>
>>    of flow for more detailed inspection.
>>
>> My point is that the architecture does not actually forbid the 
>> possibility of adding additional information into DetNet packets that 
>> could be used as vectors for tracking/correlation. This change would 
>> also address my concern about the OAM piece, but if you or the WG 
>> want to pursue further edits regarding OAM given Greg’s mail I’m 
>> happy to review.
>>
>> Best,
>>
>> Alissa
>>
>>
>>
>>
>>
>>         This edit also doesn’t seem to cover the potential for
>>         additional privacy exposure implied by the discussion of OAM
>>         in Section 4.1.1:
>>
>>     Thank you for making clear that this is the text you mean under
>>     "novel flow IDs and OAM tags" below. It was not clear to me
>>     because the architecture document does not contain either new /
>>     novel   Flow ID / OAM tag.
>>
>>
>>         "OAM can involve specific tagging added in the packets for
>>         tracing implementation or
>>
>>            network configuration errors; traceability enables to find
>>         whether a
>>
>>            packet is a replica, which DetNet relay node performed the
>>
>>            replication, and which segment was intended for the replica.
>>
>>
>>     This text is there since:
>>     https://tools.ietf.org/html/draft-finn-detnet-architecture-05.
>>
>>
>>         Active
>>
>>            and hybrid OAM methods require additional bandwidth to
>>         perform fault
>>
>>            management and performance monitoring of the DetNet
>>         domain.  OAM may,
>>
>>            for instance, generate special test probes or add OAM
>>         information
>>
>>            into the data packet.”
>>
>>     This was added based on
>>     https://www.ietf.org/mail-archive/web/detnet/current/msg01577.html.
>>
>>     This paragraph reads to me as pretty generic text on OAM.
>>
>>     What specific cahnge would you like to see made to this text?
>>
>>     Should we, e.g., update the first sentence of the paragraph to:
>>        OAM can support tracing implementation or
>>        network configuration errors. Traceability enables to find
>>     whether a
>>        packet is a replica, which DetNet relay node performed the
>>        replication, and which segment was intended for the replica.
>>
>>     ?
>>
>>     Regards,
>>     János
>>
>>
>>
>>
>>         Thanks,
>>
>>         Alissa
>>
>>
>>
>>
>>                 I'm not sure what "references to new flow IDs and OAM
>>                 tags should be removed"?
>>
>>                 Could you point to the text that should be changed?
>>
>>                 Thank you!
>>                 Janos
>>
>>                 On 2/20/2019 4:39 PM, Lou Berger wrote:
>>
>>                     On 2/20/2019 10:25 AM, Alissa Cooper wrote:
>>
>>
>>
>>                             On Feb 20, 2019, at 7:17 AM, Lou Berger
>>                             <lberger@labn.net
>>                             <mailto:lberger@labn.net>> wrote:
>>
>>                             Hi Alissa,
>>
>>                             Thanks for the comments - see below.
>>
>>                             On 2/20/2019 9:54 AM, Alissa Cooper wrote:
>>
>>                                 Alissa Cooper has entered the
>>                                 following ballot position for
>>                                 draft-ietf-detnet-architecture-11:
>>                                 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 IESG
>>                                 DISCUSS and COMMENT positions.
>>
>>
>>                                 The document, along with other ballot
>>                                 positions, can be found here:
>>                                 https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/
>>
>>
>>
>>                                 ----------------------------------------------------------------------
>>                                 DISCUSS:
>>                                 ----------------------------------------------------------------------
>>
>>                                 = Section 6 =
>>
>>                                 "DetNet is provides a Quality of
>>                                 Service (QoS), and as such, does not
>>                                    directly raise any new privacy
>>                                 considerations."
>>
>>                                 This seems like a false statement
>>                                 given the possibility that DetNet may
>>                                 require
>>                                 novel flow IDs and OAM tags that
>>                                 create additional identification and
>>                                 correlation risk beyond existing
>>                                 fields used to support QoS today.
>>
>>
>>                             Based on the other work in the WG, I
>>                             think "is not expected" is more accurate
>>                             than "does not". This is based on the WG
>>                             solutions for the DetNet data plane using
>>                             existing IP (v4 or 6) headers or MPLS
>>                             labels for flow identification.
>>
>>                         If that is the case then the references to
>>                         new flow IDs and OAM tags should be removed
>>                         from the architecture.
>>
>>                     sounds reasonable.  Can you point to the specific
>>                     offending text?
>>
>>                     Thanks,
>>
>>                     Lou
>>
>>
>>
>>
>>                             Would changing to "is not expected"
>>                             address your concern?
>>
>>                         Combined with the above removals, that would
>>                         work for me.
>>
>>                         Thanks,
>>
>>                         Alissa
>>
>>
>>
>>
>>                             Thanks,
>>
>>                             Lou
>>
>>
>>
>>
>>                         _______________________________________________
>>
>>                         detnet mailing list
>>
>>                         detnet@ietf.org  <mailto:detnet@ietf.org>
>>
>>                         https://www.ietf.org/mailman/listinfo/detnet
>>
>