So, I¹ve not been very involved in this process (not at all, really, although I¹ve worked on standards before), but my 2 cents from version 17:
"For example, findings of loss and jitter in VoIP traffic can be a predictor of future customer dissatisfaction (supported by metadata from the RTP/RTCP protocol ) [RFC3550], or increases in DNS response time can generally make interactive web browsing appear sluggish. But to detect such problems, the application or service stream must first be distinguished from others.² Remark: crypto protocols often rely on plaintext counters on the black side (to protect against replay). Jitter can also be detected by spotting holes in these counters. "2.1.3. Traffic Analysis Fingerprinting Fingerprinting is used in traffic analysis and monitoring to identify traffic streams that match certain patterns. This technique can be used with both clear text or encrypted sessions.² Remark: Yes, but obviously with different success rates. Also, the fact that traffic is encrypted is a fingerprinting characteristic in itself. Also, crypto protocols have a tendency to contain fingerprintable elements on the outside of the envelope (eg. Two Ipsec tunnels between the same endpoints). This requires cooperation with the crypto operators. But I think that somehow, that is one of the purposes of this document. "2.2.1. Load Balancers² Remark: '5-tuple' is unexplained at this point in the document. Remark @2.3.1.: at the risk of sounding somewhat political: are there really any legit use cases for people wanting to inspect / stop DNS traffic? "Another form of content filtering is called parental control² Remark: parental control is a private arrangement - shouldn¹t that always be solved at the application end, where data is plaintext anyway? Chapter 3: Why is 'Hosting SP' Environments abbreviated the way it is? It just seems to read a bit awkwardly.. Remark: Chapter 3 seems to have been written by someone completely new in comparison to the other chapters. Also, 2-tuple and 5-tuple re-emerge here, and are re-defined, although the terms have been used before. "While overlay network data encapsulations may be used to indicate the desired isolation, this is not sufficient to prevent deliberate attacks that are aware of the use of the overlay network.² Remark: I don¹t understand this sentence. How does data encapsulation indicate anything? Isn't it 'provide' in this context? And if it is 'indicate' (as in, from the perspective of the monitor (?)), then the main sentence seems to me to make no sense. 3.2.2: "Many efforts are emerging to improve user-to-user encryption, including promotion of PGP and newer efforts such as Dark Mail [DarkMail]. Of course, SPAM filtering will not be possible on encrypted content." Remark: Is this really a practical example? user-to-user email authenticated with PGP is almost by its very nature not SPAM. 3.3.1 "If session encryption is also used, the protocol is likely to be TLS." Remark: Does this sentence add anything? 3.3.2: General remark: Disk encryption doesn't seem to have an awful lot to do with monitoring of network streams. 3.3.2: "Transport encryption is likely via TLS." Remark: Does this sentence add anything? 3.3.2.1: ..."or intellectual property if session encryption via TLS is not deployed." Remark: Why this emphasis on TLS? 3.3.3.1 Remark: 'Of' in title should be 'of'. 3.3.3.1: "or with transport mode, a 5-tuple." Is that true? Doesn't IPsec transport mode also wrap the payload completely (and replace the IPPROTO field), thereby hiding 3 of 5 tuples just as well? ... I¹m going to stop here, because I¹m feeling like I¹m way too critical for someone who has hardly bothered with this group before. If so, sorry. KJ On 31/01/18 20:05, "OPSAWG on behalf of [email protected]" <[email protected] on behalf of [email protected]> wrote: > >A new version (-16) has been submitted for draft-mm-wg-effect-encrypt: >https://www.ietf.org/internet-drafts/draft-mm-wg-effect-encrypt-16.txt > > >The IETF datatracker page for this Internet-Draft is: >https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ > >Diff from previous version: >https://www.ietf.org/rfcdiff?url2=draft-mm-wg-effect-encrypt-16 > >Please note that it may take a couple of minutes from the time of >submission >until the diff is available at tools.ietf.org. > >IETF Secretariat. > >_______________________________________________ >OPSAWG mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
