Re: [arch-d] draft-iab-m-ten-workshop

[Hesham ElBakoury <[e-mail]>]

Professor Boutaba and his team in the university of Waterloo have good
papers on handling encrypted traffic. Examples are:

1)https://www.sciencedirect.com/science/article/abs/pii/S1389128623000932
2)https://dl.acm.org/doi/10.1145/3447382
3)https://arxiv.org/pdf/2308.02182
4)
https://www.researchgate.net/profile/Navid-Malekghaini/publication/368722877_Deep_learning_for_encrypted_traffic_classification_in_the_face_of_data_drift_An_empirical_study/links/6431cb5e4e83cd0e2f9d3a23/Deep-learning-for-encrypted-traffic-classification-in-the-face-of-data-drift-An-empirical-study.pdf

Hesham

On Mon, Aug 14, 2023, 1:22 PM Wes Hardaker <[e-mail]> wrote:

> Eliot Lear <[e-mail]> writes:
>
> > Hi everyone,
>
> Hi Eliot and Arnaud,
>
> I'm responding to the larger point you both had concerned with together
> about the nature of the wording and the purpose of the IAB workshop
> report.  Thank you both for your extensive comments about the content.
>
> > To begin with, it's nice when a report can seamlessly join various
> > workshop components, but this report goes so far as to appear to be
> > itself a position paper.  There are a great many unsupported and
> > otherwise unattributed assertions made.  Under Chatham House rules one
> > might expect such assertions along the lines of, “[one person/several
> > people] suggested that...”
>
> I think the general of how best to describe what happens in an IAB
> workshop and what the report entails is an interesting one, and I'm
> surprised it hasn't been brought up before (well, at least to my
> knowledge so it may very much have been in past discussions).  IAB
> workshop reports (IMHO) are designed not to assert the veracity of the
> statements within, but rather to capture the discussion and the
> statements that participants made either in presentations or in ensuing
> discussions.  So, to some extent the entire report should be read as
> "[one person/several people] suggested that"...  To that end, we [the
> IAB] did discuss the best way to represent this and have published a -02
> version with a number of changes, including a new section in the
> introduction to make this more clear which I'll quote below:
>
>     1.1.  About this workshop report content
>
>        This document is a report on the proceedings of the workshop.  The
>
>        views and positions documented in this report are those of the
>
>        expressed during the workshop by participants and do not
> necessarily
>        reflect IAB views and positions.
>
>        Furthermore, the content of the report comes from presentations
> given
>        by workshop participants and notes taken during the discussions,
>
>        without interpretation or validation.  Thus, the content of this
>
>        report follows the flow and dialog of the workshop but does not
>
>        attempt to capture a consensus.
>
> The full diff between -01 and -02 can be found here:
>
>   https://author-tools.ietf.org/iddiff?url2=draft-iab-m-ten-workshop-02
>
> Most of the rest of your comments were about specific statements that
> you disagreed with, but were made during the course of the workshop by
> at least "[one person/several people]".
>
> Note that the full recordings are on the IETF youtube channel as well:
>
> https://www.youtube.com/watch?v=Kizk_QrIc3s
> https://www.youtube.com/watch?v=aV1pzuCduLo
> https://www.youtube.com/watch?v=p4NlZJlactE
>
> A number of your comments were requesting references:
>
> > Great!  Reference, please?
>
> We did not include references to work, but rather included references to
> the individual position papers which themselves often contained
> references.  And the youtube presentations also have discussions from
> the presenters and comments that will give rise to additional information.
>
> >     Within the IETF, the Manufacturer Usage Description Specification
> (MUDD) {?RFC8520} specification is one
> >     subset of contracts. Note that contracts are likely to only succeed
> in a constrained, expected environment
> >     maintained by operational staff, and may not work in an open
> internet environment where end users are
> >     driving all network connections.
> >
> > The initial demonstration implementation of MUD (one D) was
> > implemented using a plugin to DNSCAP that itself issued commands to
> > iptables.
>
> FYI, fixed the typo in MUD.  Thanks for catching that.
>
> > There are two real questions hiding here:
> >
> >  1. Are firewall vendors and telcos have an interest in protecting the
> user with such contractors?  The user
> >     certainly has that interest.
> >  2. Can a contract be properly described and maintained in a secure way?
> >
> > There has been some academic work on answering the latter
> > question.[1,2]  Going further, though, some aspects of MUD (and
> > Michael could say a good bit about this, and probably did at the
> > workshop), require visibility.   So for instance, rather than making
> > use of DNSCAP, a more explicit API between the resolver and the rest
> > of network management is something that has been discussed in various
> > corners (if memory serves, dnsop just recently).  This very much
> > depends on whether the endpoint uses a resolver with that sort of
> > binding.  Future work, I suppose.
>
> I've argued recently that half (if not more) of an IAB workshop is to
> start the discussion and direction, and rarely should the workshop
> actually solve a problem.  The point is to get people in the room so a
> conversation starts, even if there isn't agreement at the end.  To that
> end, there should *always* (IMHO) be future work after an IAB workshop.
> For if there isn't and the problem was actually solved during the
> workshop, it probably should have been a working group instead of a
> workshop :-)
>
> --
> Wes Hardaker
> USC/ISI
>
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>