Subject: Re: [Detnet] detnet architecture, and privacy considerations

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Tue, 7 Jun 2016 19:42:32 +0000

Good points.  I should add a section on privacy considerations.  Points to make in that section would include (this is not proposed text):

 1. DetNet is aimed at enterprise-sized networks under a single administration, not service provider or Big-I Internet situations.  Most use cases (industrial, automotive, AV studio) involve planned, engineered, work-oriented data flows where privacy is not an issue.  In particular, streaming content delivery to individuals is not a target for DetNet.
 2. However, the requirement for every node along the path to identify the stream certainly does seem to conflict with random address changes, as do long-lived flows, in general.  This may well present an additional attack surface for privacy, should the DetNet paradigm be found useful in broader environments.

Any other points that should be made?

— Norm

From: detnet <[email-masked]<mailto:[email-masked]>> on behalf of "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 6, 2016 at 09:58 AM
To: Tim Chown <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Detnet] OFFLIST RE: detnet architecture, and privacy considerations

Hi Tim,

I do fully agree with this comment.

FWIW, there are some considerations that are discussed in https://tools.ietf.org/html/rfc7297#section-3.8 that may be reused in the context of detnet.

IMHO, the privacy requirement should be explicitly captured in the use case draft, but as that draft is currently scoped, it is hard to see how requirements are derived from the use cases.

Cheers,
Med

De : detnet [mailto:[email-masked]] De la part de Tim Chown
Envoyé : mardi 5 avril 2016 13:43
À : [email-masked]<mailto:[email-masked]>
Objet : [Detnet] detnet architecture, and privacy considerations

Hi,

The question I asked at the mic today was driven by seeing an architecture text (draft-finn-detnet-architecture-04) where there’s no explicit mention of privacy handling, and being aware that since RFC 7258 was published we should be thinking about appropriate privacy considerations in such documents.

So, for example, one ‘open issue' slide in Norman’s talk asked about identifying streams, and L2 addresses or the 5-tuple were mentioned, but in a world where L2 addresses are randomised over time, and encryption is more widespread, other mechanisms may be required, ones that one might argue should be opaque to the network operator.

Wearing my dnssd WG chair hat, we’ve discussed similar issues this week, specifically how you might do device naming and service discovery with privacy, while using ‘broadcast’ protocols such as mDNS and DNS-SD (see https://www.ietf.org/proceedings/95/slides/slides-95-dnssd-0.pdf, if interested).

Whatever privacy considerations are put into the architecture, I think we should at least ensure we discuss them, noting that while detnet is scoped by charter to initially only be applicable within a single administrative domain, use of the word ‘initially’ implies its scope may/will grow later.

Tim

---

From: Lou Berger <[email-masked]>
Date: Wed, 8 Jun 2016 22:04:45 -0400

Can someone send me a copy of the latest arch doc? bitbucket says the
account has hit it's user limit.  Why not just use github?

Thanks,

Lou

On 6/7/2016 3:42 PM, Norman Finn (nfinn) wrote:
> Good points.  I should add a section on privacy considerations.
>  Points to make in that section would include (this is not proposed text):
>
>  1. DetNet is aimed at enterprise-sized networks under a single
> administration, not service provider or Big-I Internet situations.
>  Most use cases (industrial, automotive, AV studio) involve planned,
> engineered, work-oriented data flows where privacy is not an issue.
>  In particular, streaming content delivery to individuals is not a
> target for DetNet.
>  2. However, the requirement for every node along the path to identify
> the stream certainly does seem to conflict with random address
> changes, as do long-lived flows, in general.  This may well present an
> additional attack surface for privacy, should the DetNet paradigm be
> found useful in broader environments.
>
> From: detnet <[email-masked]
> <mailto:[email-masked]>> on behalf of
> "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
> To: Tim Chown <[email-masked] <mailto:[email-masked]>>,
> "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
>     FWIW, there are some considerations that are discussed in
>     https://tools.ietf.org/html/rfc7297#section-3.8 that may be reused
>     in the context of detnet.
>
>      
>
>     IMHO, the privacy requirement should be explicitly captured in the
>     use case draft, but as that draft is currently scoped, it is hard
>     to see how requirements are derived from the use cases.
>
>      
>
>     Cheers,
>
>     Med
>
>      
>
>     *De :*detnet [mailto:[email-masked]] *De la part de* Tim
>     Chown
>     *Envoyé :* mardi 5 avril 2016 13:43
>     *À :* [email-masked] <mailto:[email-masked]>
>     *Objet :* [Detnet] detnet architecture, and privacy considerations
>
>      
>
>     Hi,
>
>      
>
>     The question I asked at the mic today was driven by seeing an
>     architecture text (draft-finn-detnet-architecture-04) where
>     there’s no explicit mention of privacy handling, and being aware
>     that since RFC 7258 was published we should be thinking about
>     appropriate privacy considerations in such documents.
>
>      
>
>     So, for example, one ‘open issue' slide in Norman’s talk asked
>     about identifying streams, and L2 addresses or the 5-tuple were
>     mentioned, but in a world where L2 addresses are randomised over
>     time, and encryption is more widespread, other mechanisms may be
>     required, ones that one might argue should be opaque to the
>     network operator. 
>
>      
>
>     Wearing my dnssd WG chair hat, we’ve discussed similar issues this
>     week, specifically how you might do device naming and service
>     discovery with privacy, while using ‘broadcast’ protocols such as
>     mDNS and DNS-SD
>     (see https://www.ietf.org/proceedings/95/slides/slides-95-dnssd-0.pdf,
>     if interested).
>
>      
>
>     Whatever privacy considerations are put into the architecture, I
>     think we should at least ensure we discuss them, noting that while
>     detnet is scoped by charter to initially only be applicable within
>     a single administrative domain, use of the word ‘initially’
>     implies its scope may/will grow later.
>
>      
>
>     Tim
>
>      
>
>      
>
>      
>
>
>
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 8 Jun 2016 21:11:23 -0700

attached.

> On 08 Jun 2016, at 19:04, Lou Berger <[email-masked]> wrote:
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 09 Jun 2016 04:19:33 -0400

Woops. This was supposed to be unicast to the authors.  Please excuse the 
noise!

Lou

Ps thanks Jouni

On June 9, 2016 12:12:10 AM Jouni Korhonen <[email-masked]> wrote:

> ----------
> ----------

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Mon, 13 Jun 2016 19:44:16 +0000

Hi Norm, Pascal, Michael,
I read over the architecture doc again and I found it quite readable. I came up with a few minor typos and a couple of questions, below.
Ethan.
-----------------------------------
1)  " When combining member flows that take different-length paths through
   the network, and which are also guaranteed a worst-case latency by
   packet shaping, a merge point may require extra buffering to equalize
   the delays over the different paths.  This equalization ensures that
   the resultant compound flow will not exceed its contracted bandwidth
   even after one or the other of the paths is restored after a failure."

--> Is the point that the flow with longer latency inherently requires more buffering, and that such buffering is directly related to its contracted bandwidth? The bad case apparently would be if unequal latency paths were not equalized, then say the short one failed leaving the long one, then the short one was reinstated... how would bandwidth be exceeded? Somehow I'm missing something here.

2) "The presence in the network of relay nodes that are not fully capable
   of offering DetNet services complicates the ability of the relay
   nodes and/or controller to allocate resources, as extra buffering,
   and thus extra latency, must be allocated at points downstream from
   the non-DetNet relay node for a DetNet flow."

--> If the worst case latency of the non-DetNet relay is potentially unbounded, how can including it as a hop even with extra buffering allow a worst case latency for the path to be guaranteed? Does "not fully capable" have an implicit specific meaning? 

3) Typo (extra "with" at "coexist with with"):
  " A DetNet network supports the dedication of a high proportion (e.g.
   75%) of the network bandwidth to DetNet flows.  But, no matter how
   much is dedicated for DetNet flows, it is a goal of DetNet to coexist
   with with existing Class of Service schemes (e.g., DiffServ).  It is
   also important that non-DetNet traffic not disrupt the DetNet flow,
   of course (see Section 4.5 and Section 7)."  

4) Typo (Per-fFlow):
"One or more PCE(s) collaborate to implement the requests from the FME
   as Per-fFlow Per-Hop Behaviors installed in the relay nodes for each
   individual flow."

5) Typo (abel):
"A Label Edge Router (LERs) may have a abel Switched Path (LSP)"

6) Typo: ("_with_ an underlying..."?) (maybe just re-use the extra with from item 3)
 " The integration/interaction of the DetNet control layer an underlying
   IEEE 802.1 sub-network control layer will need to be defined."

7) Need references (eventually...):
"There exist techniques, at present and/or in various stages of
   standardization, that can perform these fault mitigation tasks"
-----------------------------------

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Wed, 22 Jun 2016 21:36:44 +0000

See in-line

-----Original Message-----
From: "Grossman, Ethan A." <[email-masked]>
Date: Monday, June 13, 2016 at 12:44 PM
To: Norman Finn <[email-masked]>, Michael Teener <[email-masked]>,
Pascal Thubert <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [Detnet] detnet architecture, and privacy considerations

>I read over the architecture doc again and I found it quite readable. I
>came up with a few minor typos and a couple of questions, below.
>Ethan.
>--> Is the point that the flow with longer latency inherently requires
>more buffering, and that such buffering is directly related to its
>contracted bandwidth? The bad case apparently would be if unequal latency
>paths were not equalized, then say the short one failed leaving the long
>one, then the short one was reinstated... how would bandwidth be
>exceeded? Somehow I'm missing something here.

The problem occurs when the low-latency (short) path fails are recovers.
See:

http://www.ieee802.org/1/files/public/docs2015/cb-nfinn-seamless-issues-101
5-v02.pdf

(no username/password required) for a full explanation.  Basically, let’s
suppose you have a 1Mb/s reservation that you’re multi-patting.  There is
a long path and a short path.  When the short path fails, there is a gap
for a while, because the slow path contains only repeats until you get up
to the point where the short path failed.  When the short path recovers,
you have a double load of data you’d like to transmit.  You have to buffer
that short path data at the junction until the slow path catches up, and
then start throwing away every other packet.  If you don’t buffer, then
you would have to run the output port at > 1 Mb/s until you catch up.

>--> If the worst case latency of the non-DetNet relay is potentially
>unbounded, how can including it as a hop even with extra buffering allow
>a worst case latency for the path to be guaranteed? Does "not fully
>capable" have an implicit specific meaning?

If the worst-case latency of a non-detent relay is truly unbounded, you’re
hosed.

From a practical standpoint, people engineer networks today by using high
priority for the critical traffic, and putting network control traffic
(e.g. Spanning tree or OSPF packets) at something lower.  People do
network calculus in controllers or off-line, or sometimes something less
sophisticated (e.g. a wild guess) on the worst-case latency through that
device.  It is the (worst case) - (best case) difference that requires
buffering in the next node.

>   IEEE 802.1 sub-network control layer will need to be defined."

Got ‘em.  Thanks.

>   standardization, that can perform these fault mitigation tasks"

Shouldn’t be hard to provide non-normative references.

Thanks, Ethan.

— Norm

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 28 Jun 2016 02:09:15 +0000

Got it, all clear now, thanks Norm. 
Ethan.

-----Original Message-----
From: Norman Finn (nfinn) [mailto:[email-masked]] 
Sent: Wednesday, June 22, 2016 2:37 PM
To: Grossman, Ethan A.; Michael Johas Teener ([email-masked]); Pascal Thubert (pthubert)
Cc: [email-masked]
Subject: Re: [Detnet] detnet architecture, and privacy considerations

See in-line

-----Original Message-----
From: "Grossman, Ethan A." <[email-masked]>
Date: Monday, June 13, 2016 at 12:44 PM
To: Norman Finn <[email-masked]>, Michael Teener <[email-masked]>, Pascal Thubert <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [Detnet] detnet architecture, and privacy considerations

>contracted bandwidth? The bad case apparently would be if unequal 
>latency paths were not equalized, then say the short one failed leaving 
>the long one, then the short one was reinstated... how would bandwidth 
>be exceeded? Somehow I'm missing something here.

(no username/password required) for a full explanation.  Basically, let’s suppose you have a 1Mb/s reservation that you’re multi-patting.  There is a long path and a short path.  When the short path fails, there is a gap for a while, because the slow path contains only repeats until you get up to the point where the short path failed.  When the short path recovers, you have a double load of data you’d like to transmit.  You have to buffer that short path data at the junction until the slow path catches up, and then start throwing away every other packet.  If you don’t buffer, then you would have to run the output port at > 1 Mb/s until you catch up.

>unbounded, how can including it as a hop even with extra buffering 
>allow a worst case latency for the path to be guaranteed? Does "not 
>fully capable" have an implicit specific meaning?

If the worst-case latency of a non-detent relay is truly unbounded, you’re hosed.

From a practical standpoint, people engineer networks today by using high priority for the critical traffic, and putting network control traffic (e.g. Spanning tree or OSPF packets) at something lower.  People do network calculus in controllers or off-line, or sometimes something less sophisticated (e.g. a wild guess) on the worst-case latency through that device.  It is the (worst case) - (best case) difference that requires buffering in the next node.

>6) Typo: ("_with_ an underlying..."?) (maybe just re-use the extra with 
>from item 3)  " The integration/interaction of the DetNet control layer 
>an underlying

Got ‘em.  Thanks.

Thanks, Ethan.

— Norm