Subject: [Detnet] OFFLIST RE: detnet architecture, and privacy considerations

From: <[email-masked]>
Date: Wed, 6 Apr 2016 16:58:33 +0000

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]
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: "Grossman, Ethan A." <[email-masked]>
Date: Wed, 6 Apr 2016 18:50:12 +0000

Hi Tim and Mohamed,
Thanks for bringing this up. Clearly security is a major requirement of DetNet use cases. Please pardon my ignorance here, but does privacy as defined in this context affect security on a “centrally administered corporate network” (such as DetNet is currently defined to operate on)? If it does then I would say we need to add it to the use cases draft explicitly; however if it only becomes an issue in a possible post-DetNet time frame then it might be considered as an element of the currently open question “to what extent does planning for future application of DetNet to public networks affect DetNet design decisions today?”
Thanks,
Ethan.

From: detnet [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, April 06, 2016 1:59 PM
To: Tim Chown; [email-masked]
Subject: [Detnet] OFFLIST RE: detnet architecture, and privacy considerations

Hi Tim,

FWIW, there are some considerations that are discussed in https://tools.ietf.org/html/rfc7297#section-3.8<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7297-23section-2D3.8&d=CwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=bxSmtxiQmHaUBA3arrcZTsmSzZ2YPdEZLir2SSA-Uts&s=s3zhb9Mth3IJbtD3Q13Goqwyqfa0g00R0sJeMrOkabY&e=> that may be reused in the context of detnet.

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,

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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_proceedings_95_slides_slides-2D95-2Ddnssd-2D0.pdf&d=CwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=bxSmtxiQmHaUBA3arrcZTsmSzZ2YPdEZLir2SSA-Uts&s=I_F9OkprxSt772GIh8bbnoL5hV2Agv-B_GufMws9c9k&e=>, if interested).

Tim