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

[Arnaud Taddei <[e-mail]>]

Thank you Hesham, I will educate myself in the (too many) forthcoming trips.

Whilst I am sure this approach can help, I am taking it from a different point of view which basically boils down to ‘I cannot afford playing dice with the security of organizations and people’ especially when I see Ransomware damaging so much this world.

From: Architecture-discuss <[e-mail]> on behalf of Hesham ElBakoury <[e-mail]>
Date: Monday, 14 August 2023 at 23:29
To: Wes Hardaker <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [arch-d] draft-iab-m-ten-workshop
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<https://www.google.com/url?q=https://www.sciencedirect.com/science/article/abs/pii/S1389128623000932&source=gmail-imap&ust=1692653392000000&usg=AOvVaw156PPnjCWC5AWlIlm-sKTP>
2)https://dl.acm.org/doi/10.1145/3447382<https://www.google.com/url?q=https://dl.acm.org/doi/10.1145/3447382&source=gmail-imap&ust=1692653392000000&usg=AOvVaw2TVawa1ZzzJI3XvfvSnMI->
3)https://arxiv.org/pdf/2308.02182<https://www.google.com/url?q=https://arxiv.org/pdf/2308.02182&source=gmail-imap&ust=1692653392000000&usg=AOvVaw2OOeAMSM_a1GAfQYx0KEE9>
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<https://www.google.com/url?q=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&source=gmail-imap&ust=1692653392000000&usg=AOvVaw0wTPRNqp3us8soQk1QmOwI>

Hesham

On Mon, Aug 14, 2023, 1:22 PM Wes Hardaker <[e-mail]<mailto:[e-mail]>> wrote:
Eliot Lear <[e-mail]<mailto:[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<https://www.google.com/url?q=https://author-tools.ietf.org/iddiff?url2%3Ddraft-iab-m-ten-workshop-02&source=gmail-imap&ust=1692653392000000&usg=AOvVaw3bWL4OFgd3fttCLZEOdxxz>

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.google.com/url?q=https://www.youtube.com/watch?v%3DKizk_QrIc3s&source=gmail-imap&ust=1692653392000000&usg=AOvVaw1dtj0H4avRj3i-U14V8_X9>
https://www.youtube.com/watch?v=aV1pzuCduLo<https://www.google.com/url?q=https://www.youtube.com/watch?v%3DaV1pzuCduLo&source=gmail-imap&ust=1692653392000000&usg=AOvVaw3VJypoKu_tLB9hGIWwOyN_>
https://www.youtube.com/watch?v=p4NlZJlactE<https://www.google.com/url?q=https://www.youtube.com/watch?v%3Dp4NlZJlactE&source=gmail-imap&ust=1692653392000000&usg=AOvVaw1n2tfhTEn7wRtvMHECJha2>

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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/architecture-discuss<https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/architecture-discuss&source=gmail-imap&ust=1692653392000000&usg=AOvVaw3e7j6K8CJwrxzIbKf2n8aS>

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.