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

From: Alissa Cooper <[email-masked]>
Date: Fri, 12 Apr 2019 13:08:02 -0400

Hi János,

> On Mar 25, 2019, at 12:16 PM, János Farkas <[email-masked]> 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://tools.ietf.org/html/draft-ietf-detnet-architecture-12>. (https://mailarchive.ietf.org/arch/msg/detnet/utVL9ZVGcOeGtRIASRFx5WT_ErM <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.

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:

"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.  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.”

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 <[email-masked] <mailto:[email-masked]>> 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 <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/ <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
>>>> [email-masked] <mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/detnet <https://www.ietf.org/mailman/listinfo/detnet>
>> 
>

---

From: János Farkas <[email-masked]>
Date: Mon, 15 Apr 2019 23:08:02 +0200

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 <[email-masked] 
>> <mailto:[email-masked]>> 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)
>>
> 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 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?

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

> 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

>>>>>>> Please refer to 
>>>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> 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.
>>>>
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/detnet
>>>
>>
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 16 Apr 2019 18:29:10 -0700

Hi Alisa,
I agree with your observation that the reporting of the location of
replication, duplicate elimination and the order preservation functions
within a DetNet domain presents the new security concern and may be the
threat to the privacy of data. To address your concern, may I propose the
following text:
   To protect against unauthorized sources trying to obtain DetNet network
information,
   e.g., location of replication, elimination, or packet order preservation
functions,
   it is RECOMMENDED that DetNet implementations provide a means
   of checking the source addresses of queries against an access list
before accepting
   them.

We'll have a more detailed analysis of the new security threats possible
resulting from specific to DetNet OAM functions in the DetNet OAM draft
<https://datatracker.ietf.org/doc/draft-mirsky-detnet-oam/>.

Best regards,
Greg

On Fri, Apr 12, 2019 at 10:08 AM Alissa Cooper <[email-masked]> wrote:

> revision: https://tools.ietf.org/html/draft-ietf-detnet-architecture-12. (
> https://mailarchive.ietf.org/arch/msg/detnet/utVL9ZVGcOeGtRIASRFx5WT_ErM)
>
> 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.
>
> 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:
>
> On Feb 20, 2019, at 7:17 AM, Lou Berger <[email-masked]> wrote:
>
> Hi Alissa,
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> 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.
>
>
> detnet mailing [email-masked]://www.ietf.org/mailman/listinfo/detnet
>
>
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 17 Apr 2019 10:56:02 +0100

Alisa

At the moment we only have an MPLS data-plane that supports PREOF 
although an IPv6 one may perhaps follow one day.

In the case of MPLS the usual security model applies, in that the
network is well managed, and the only way to get a packet into or out of 
the the network is via an trusted router that immediately encapsulates 
the packet or removes any internal encapsulation/metadata.

If we manage to develop an IP version, my expectation is that
it would need an enhancement to the IPv6 data plane, in which case
the design should use the security features that will inevitably 
required to make SRv6 secure.

The other data-plane that we have uses MPLS over UDP encapsulation
and needs to inherit the security model from draft-ietf-mpls-sr-over-ip,
but that needs to called up the specific data plane specification.

I do not see any privacy concerns that are specific to DetNet in the
operation of the network.

If you are thinking about external tags needed on entry to the network
there are none currently specified in the data-plane design. If we
introduced any such tags they would raise a huge security issue and the 
design would inevitably be subjected to a tough security analysis.

- Stewart

On 17/04/2019 02:29, Greg Mirsky wrote:
> threat to the privacy of data. To address your concern, may I propose 
> the following text:
>     To protect against unauthorized sources trying to obtain DetNet 
> network information,
>     e.g., location of replication, elimination, or packet order 
> preservation functions,
> resulting from specific to DetNet OAM functions in theDetNet OAM draft 
> On Fri, Apr 12, 2019 at 10:08 AM Alissa Cooper <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi János,
> 
> 
>>     On Mar 25, 2019, at 12:16 PM, János Farkas
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Hi Alissa,
>>
>     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.
> 
>>>>>>     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.
>>>>>
>>>>>     https://www.ietf..org/mailman/listinfo/detnet  <https://www.ietf.org/mailman/listinfo/detnet>
>>>
>>
>

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 17 Apr 2019 09:33:31 -0400

Hi János,

> On Apr 15, 2019, at 5:08 PM, János Farkas <[email-masked]> wrote:
> 
> Hi Alissa,
> 
> Please see in-line.
> 
>>> On Mar 25, 2019, at 12:16 PM, János Farkas <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Alissa,
>>> 
> 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.

> https://mailarchive.ietf.org/arch/msg/detnet/-L_wsGPMqNEOtPMgsGYaJ30nFXk <https://mailarchive.ietf.org/arch/msg/detnet/-L_wsGPMqNEOtPMgsGYaJ30nFXk>
> 
> Flow ID and associated QoS is not a new concept introduced by DetNet; therefore, does not expected to raise new concerns.
> 

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

> 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.
> 
>> 
> This text is there since: https://tools.ietf.org/html/draft-finn-detnet-architecture-05 <https://tools.ietf.org/html/draft-finn-detnet-architecture-05>.
> 
>> Active
> This was added based on https://www.ietf.org/mail-archive/web/detnet/current/msg01577.html <https://www.ietf.org/mail-archive/web/detnet/current/msg01577.html>.
>

---

From: "Black, David" <[email-masked]>
Date: Thu, 18 Apr 2019 16:52:02 +0000

+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 <[email-masked]> On Behalf Of Alissa Cooper
Sent: Wednesday, April 17, 2019 9:34 AM
To: János Farkas
Cc: [email-masked]; [email-masked]; Lou Berger; IESG; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi Alissa,

Please see in-line.

On Mar 25, 2019, at 12:16 PM, János Farkas <[email-masked]<mailto:[email-masked]>> 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)

Regards,
Janos

We can replace

Best,
Alissa

This text is there since: https://tools.ietf.org/html/draft-finn-detnet-architecture-05.

Active

   into the data packet.”
This was added based on https://www.ietf.org/mail-archive/web/detnet/current/msg01577.html.

?

Regards,
János

Thanks,

Alissa

Thank you!
Janos

On Feb 20, 2019, at 7:17 AM, Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:

Hi Alissa,

= Section 6 =

Thanks,
Alissa

Thanks,

Lou

detnet mailing list

[email-masked]<mailto:[email-masked]>

---

From: János Farkas <[email-masked]>
Date: Wed, 24 Apr 2019 20:25:56 +0200

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:
> > […] 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 <[email-masked]> *On Behalf Of *Alissa Cooper
> *Sent:* Wednesday, April 17, 2019 9:34 AM
> *To:* János Farkas
> *Cc:* [email-masked]; [email-masked]; Lou 
> Berger; IESG; [email-masked]
> *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
>             <[email-masked]
>             We believe that we have addressed your comments in the
>             most recent revision:
>         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.
>
> “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.
>
>
>
>
>     Flow ID and associated QoS is not a new concept introduced by
>     DetNet; therefore, does not expected to raise new concerns.
>
> 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.
>
>
>                             On Feb 20, 2019, at 7:17 AM, Lou Berger
>                             <[email-masked]
>                             <mailto:[email-masked]>> wrote:
>
>                             Hi Alissa,
>
>                                 This seems like a false statement
>                                 given the possibility that DetNet may
>                                 require
>                             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.
>