IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2017-04-13. These are not an official record of the meeting.
Narrative scribe: John Leslie, Susan Hares, and Ignas Bagdonas (The scribe was sometimes uncertain who was speaking.)
Corrections from: Mirja, Warren, Spencer, Deborah, Adam
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
2.2 Individual submissions
2.2.1 New items
2.2.2 Returning items
2.3 Status changes
2.3.1 New items
Telechat:
2.3.2 Returning items
3. Document actions
3.1 WG submissions
3.1.1 New items
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
3.2.2 Returning items
Telechat:
3.3 Status changes
3.3.1 New items
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
3.4.2 Returning items
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat::
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat::
Telechat::
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
7. Working Group News
7a. Other Business
1129 EDT Adjourned
(at 2017-04-13 06:00:06 PDT)
draft-ietf-ippm-6man-pdm-option
Agree with the many comments by the other ADs. Especially, Mirja's and Ben's comments, the document reads like a white paper vs. an IETF specification. The "Consent to be Measured" by a user (section 4.4) seems contra to the use case described in the document (estimate QoS as experienced by an end user device). It should be the network provider who should be giving "consent to be measured" and the associated risks. Warren also noted these sentences as inappropriate. The document discusses the security aspects relative to the user but is missing discussion with respect to the network provider.
The document says that packet sequence number are optional ("measurements based on optional sequence numbers and timing may be embedded in each packet"), but doesn't say what should be put in the PSNTP field if I'm not using them. It also doesn't say what I should put in the PSNLR field if I haven't received any PDM packets (the exmaple just has a dash). This means that I cannot create an interoperable implementation from this document alone.
This document defines a new IPv6 Destination Option. Adding this to a packet pushes the L4 information further out, potentially making it unavailable to the forwarding engine / ACLs. This is not just a theoretical issue - see RFC7872 for real world examples. This means that if I connect to a remote machine and enable this, I may lock myself out of the machine (return packets may not make it back to me); this should be noted (perhaps by expanding on section 1.6). In addition, enabling PDM will (almost definitely) add some processing / transmit time, and so will perturb the very thing being measured - I believe that the document should note this. Appendix C mentions overhead from larger packets, but nothing about the additional processing time. In addition, much of the security advice feels like sops, simply to appease security people. For example, in "PDM as a Covert Channel" we find: "Having said that, an implementation SHOULD stop using PDM if it gets some number of "nonsensical" sequence numbers." -- seeing as it would be the attacker using PDM as a convert channel, this is like saying attackers must set the evil bit on all attack traffic. Another example is section 4.4 Timing Attacks: "Even so, if using PDM, we introduce the concept of user "Consent to be Measured" as a pre-requisite for using PDM. Consent is common in enterprises and with some subscription services. So, if with PDM, we recommend that the user SHOULD consent to its use." - this has nothing to do with timing attacks. In addition a concept is introduced, but not really explained - it is then claimed that this is common in enterprises (true), and that users SHOULD consent (or should have already consented) to being monitored. This feels like it was sprinkled on like security fairy dust to make security people happy, and (for me) does the opposite. I don't understand Section 3.6 Dynamic Configuration Options. "If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=yes/no. The operating system MAY also have a dynamic configuration option to change the configuration setting as needed." I don't understand how an implementing OS could not have a default (unless this were random). If the default were no, presumably it would *have* to have a dynamic option to change the config (or it could never be enabled). Section 3.5.1 says: "The PDM destination options extension header MUST be explicitly turned on by each stack on a host node by administrative action. The default value of PDM is off.", so I'm very confused what 3.6 is trying to say...
* Section 3.2.1. The option length seems to be wrong here. This will make the parser parse incorrectly onto a following option or worse. I think this MUST be set to 10 instead of 16 (Or some field is missing from the description of the option) 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 16. * Section 3.2.1. The option does not seem to state an alignment requirement, but I think one is required to properly align the multi-byte PSN and Delta fields. Can you please specify one. * Section 5 The IANA considerations section needs to be more specific as you are requesting a specific type of option. e.g. This draft requests an Destination Option Type assignment with the act bits set to 00 and the chg bit set to 0 from the ...
* Section 1.6 I am not sure where this inference comes from. Can you please clarify? It is likely that an IPv6 packet containing PDM will be dropped if using IPv6 transition technologies. * Section 3.1 This text is not correct as the PDM option is not an implementation of the Destination options *header*. The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) is an implementation of the Destination Options Header. Suggest rewording to The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) is implemented as an IPv6 Option carried in the Destination Options Header.
My main concern is that part of this document read like an advertisement (e.g. "In our experience, valuable time is often lost.." whose experience? The IETF? This is an IETF RFC!). I think most of this text is not needed to understand the option and therefore should simply be removed. More concretely, I propose to remove sections 1.2, 1.3., and 1.5 as well as paragraphs 4-8 of section 1.4 (starting with "In our experience, valuable time is often lost..." to the end). I would also recommend these two changes to shorten the RFC: - section 3.2.3. could just be moved into the appendix. - the diagrams from RFC4303 in sections 3.4.1. and 3.4.2 are not needed In general I think another editing pass could help to bring the document more to the point in a couple of cases. But that's not really an issue. Further comments: 1) This text in 3.4.2 is a bit confusing: "As a completely new IP packet will be made, it means that PDM information for that packet does not contain any information from the inner packet, i.e. the PDM information will NOT be based on the transport layer (TCP, UDP, etc) ports etc in the inner header, but will be specific to the ESP flow. If PDM information for the inner packet is desired, the original host sending the inner packet needs to put PDM header in the tunneled packet, and then the PDM information will be specific for that stream." I think what you want to say is something like "A tunnel endpoint that creates a new packet may decide to use PDM independent of the use of PDM of the original packet to enable delay measurements between the two tunnel endpoints." Correct? 2) I'm not sure this is really useful to specify normatively in an RFC as this is really implementation specific: "The PDM destination options extension header MUST be explicitly turned on by each stack on a host node by administrative action. The default value of PDM is off." I would recommend the following text instead (without normative language): "An implementation should provide an interface to enable or disable the use of PDM. This specification recommends to turn PDM off by default." 3) I don't understand section 3.6. Isn't that redundant with 3.5.1? Or what's meant by 'dynamic configuration option'? In any case, I don't think the use of normative language is appropriate here. 4) I would also like to propose new text on 3.6 5-tuple Aging (btw. 3.6. exists twice) OLD "3.6 5-tuple Aging Within the operating system, metrics must be kept on a 5-tuple basis. The question comes of when to stop keeping data or restarting the numbering for a 5-tuple. For example, in the case of TCP, at some point, the connection will terminate. Keeping data in control blocks forever, will have unfortunate consequences for the operating system. So, the recommendation is to use a known aging parameter such as Max Segment Lifetime (MSL) as defined in Transmission Control Protocol [RFC0793] to reuse or drop the control block. The choice of aging parameter is left up to the implementation." NEW "3.6 Information Access and Storage Measurement information provided by PDM must be made accessible for higher layers or the user itself. Similar as activating the use of PDM, the implementation may also provide an interface to indicate if received PDM information should be stored or not. If a packet with PDM information is received and the information should be stored, the upper layers may be notified. Further it is recommend to define a configurable maximum lifetime after which the information can be removed as well as a configurable maximum amount of memory that should be allocated for PDM information." This text also addresses some of the "SYN flood attack" concerns as described in the security considerations section. I would recommend to rewrite this section as well and I would also recommend to not use the term SYN flood as that is clearly associated with TCP only. 5) Also section 4.1 (security consideration): I don't think this sentence is true: " For PDM, the amount of data to be kept is quite small. That is, the control block is quite lightweight." Because you eventually have to hold this data per packet, so it can grow quickly. However, this is also really an implementation question only. You could also just store the delay calculation and not the whole control block, or even an moving average of the delay which only needs a fixed amount of memory for a few values. I really depends what your use case is for the information provided by PDM.
Substantive Comments: - 1.4, 2nd to last paragraph: Please don't make assumptions about organizational models; different organizations do it differently. Does the motivation still make sense if the organization doesn't follow this model? - 1.5, first paragraph: "The purpose of the PDM is not to supplant all the variables present in all other headers but to provide data which is not available or very difficult to get." How is that different than for any other extension? 3.2.1, PSNTP definition: What are the consequences if people "spoof and insert such packets."? - 3.2.2: Are there really use cases for attosecond precision? - 4.1, last paragraph: Can you provide guidance on selecting a reasonable limit? At least a lower bound so that the limit does not negatively impact the PDM function? -4.2: Could PDM be used to (help) deduce the nature of the application, or possibly network topology? The last paragraph says it will be unhelpful in deducing content; I suspect otherwise. Section 4.4 talks about how it might help timing attacks against key material. Does PDM really offer no more information to an observer than they could get by observing packet intervals of otherwise encrypted traffic? For example, it seems like one could not differentiate between wire-time and processing-time from observation alone. -4.4, 2nd paragraph: Why does the attacker need to induce the host to turn on PDM? What about cases where the host already uses PDM? -- last paragraph:The text recommends that a user SHOULD consent. I think you mean to say that user consent SHOULD be required. They mean very different things. But along those lines, do you expect the average user to make informed consent decisions? At what scope should such decisions be made? Some OSs ask a user if they are willing to share diagnostic info at a global level. Does the guidance about using PDM on limited IP addresses or ports suggest consent apply at a smaller granularity? Editorial Comments: -General: Much of the text reads more like a white paper than an IETF standards-track RFC. This makes some sections seem like advertisements. The heavy use of "we" calls into question whether it documents the opinions of the WG, or the opinions of the authors. It also makes some sections longer than they need to be (e.g. the discussions related to time scaling factors read more like a classroom lecture than a specification.) I recognize that fixing this would require a re-write. I will leave it to the authors, chairs, and AD to decide if that is worthwhile this late in the process. - Abstract: Last sentence is long and convoluted. Please consider breaking it up. - 1.4, list of advantages: How is 5 different than 2? -- 2nd paragraph after end of list: s/"to do"/"to" - 3.2, 2nd paragraph: Please expand DTN - 3.2, last paragraph: The reference to Appendix A is worded in a way that suggests you have to read that section to understand how to implement time scaling factors. That led me to wonder why the appendix was not part of the body. But when I read the appendix, I realized that it really was additional explanation, and not a normative part of the process. Please consider something like the following: OLD: For a full description of this process... NEW: For additional discussion about this process... - 3.4.1, first paragraph: The MAY seems like a statement of fact, not a normative requirement. (Same for 3.4.2)
The analysis in Sec 4.2 seems to be missing some considerations. In cases where the packet payload is encrypted and the attacker does not have access to the keys, the attacker does not in fact have access to the entire packet, in which case PDM provides more information than a packet without PDM. Also in those cases, it seems like including PDM information would generally make a packet stream more susceptible to traffic analysis insofar as the timing and sequence information may provide additional indicators about the type of application in use, not just the speed of the end host.
No objection to the publication of this document, but it's important to get Warren's COMMENT addressed: This document defines a new IPv6 Destination Option. Adding this to a packet pushes the L4 information further out, potentially making it unavailable to the forwarding engine / ACLs. This is not just a theoretical issue - see RFC7872 for real world examples. This means that if I connect to a remote machine and enable this, I may lock myself out of the machine (return packets may not make it back to me); this should be noted (perhaps by expanding on section 1.6).
I support Warren's discuss and comments and have a few additional comments to add. Kind of related to Warren's discuss, I kept looking for a limitation to the scope for this work in the draft and didn't get to one until the end of the security considerations section. The text there wasn't quite clear enough for me. It seems that this might only be used for small periods of time while troubleshooting, is that correct? It also seems like this has to be end-to-end, is that right? And if it does need to be end-to-end, is the user aware of this troubleshooting so that they are not sending traffic that contains sensitive data that should remain confidential (security or privacy implications may also exist if this is not the case). If the scope were limited, I would not have as many security concerns. Network reconnaissance may or may not be an issue. I don't think it is, but I need to better understand the scope of use for this option. nit: s/IPSec/IPsec/g Thanks for adding in Tero's suggested text from his SecDir review, his point is important to include. Please make sure this gets into the approved version. https://mailarchive.ietf.org/arch/msg/secdir/BAIkONwtaQvH2toiTY76Ic1cakA
In Sec 3.2.1, it specifies "Delta Time Last Received = (Send time packet 2 - Receive time packet 1)" & "Delta Time Last Sent = (Receive time packet 2 - Send time packet 1)". I think this would be clearer and not subject to misinterpretation if it were "n" and "n-1" - with words indicating wrapping cases.
I think the description of timing attacks could use a bit more work. Specifically: - I am assuming that you should discard rather than using as timestamp sources packets which fail ESP. This shouldn't be an issue for transport mode because you process ESP first, but in tunnel mode you allow either order, so it's a potential issue. - It seems like you could use this technique for fine-grained timing of the cryptographic operations traffic keys as well (cf. Lucky 13), not just long-term keys as you say in S 4.4. Note that both of these attacks are not ameliorated by restricting to host and ports because one assumes that the attacker controls the network per 3552.
In Section 3.2.1. (PDM Layout), please include all the considerations related to the Option Type in the same place.
I agree with Warren's DISCUSS.
draft-ietf-pals-status-reduction
In this text, -iii. If the new value is smaller then the original one, the PE will operate according to the original timer value for a period 3.5 times the original timer value, or until the first valid PW status refresh reduction message is received. Perhaps it would be helpful to explain the choice of 3.5, so that if this mechanism is deployed for a network where that number is the wrong number, people will know how to adjust it? There are several occurrences where s/then/than/ is needed, I think. I spotted at least 3. Other nits … S/octetc/octets/ S/RECOMENDED/RECOMMENDED/ S/vaules/values/ In section 7. Security Considerations The security considerations of [RFC6478] are adequate for the proposed mechanism since the operating environment is almost identical to the one where this protocol would be deployed. It should also be noted that since this protocol is designed to be deployed between two adjacent PEs connected by a physical link, it is not possible to misdirect or inject traffic without compromising the PW transport link itself. All these situations are covered in the security considerations of [RFC6478]. There's an appeal to physical adjacency as a defensive mechanism. If this protocol is deployed in a tunnel over UDP, would “physical adjacency” still be true?
I agree with Benoit re: Jürgen's review. I was also quite confused by: " In order to get a locally unique session ID, the recommended choice is to perform a CRC-16 giving as input the following data |Y|Y|M|M|D|D|H|H|M|M|S|S|L|L|L| Where: YY: are the decimal two last digit of the current year MM: are the decimal two digit of the current month DD: are the decimal two digit of the current day HHMMSSLLL: are the decimal digits of the current time expressed in (hour, minutes, seconds, milliseconds) ... Any other method to generate a locally unique session ID is also acceptable." Is the pipe character intended to mean concatenation? Or is it just for formatting? If the former, why isn't this "YY|MM|DD|HHMMSSLLL" (or "YY|MM|DD|HH|MM|SS|LLL")? Is this just CRC-16 (170410124223001)? An example would help... Actually, this says that it is a "locally unique session ID" and that any other method is also acceptable, so why is any algorithm specified?
(important) nit in section 8.5: s/PW Sytatus Refresh Reduction/PW Status Refresh Reduction/
From Dan's Gen-ART review: Nits/editorial comments: 1. In section 8, first paragraph: s/rages/ranges/ 2. In sections 8.3, 8.4 the construct "IETF Review" is worded in three different ways (IETF review, IETF Review, "IETF Review") - better align
As mentioned by Jürgen in his OPS-DIR review: Section 1.2 is not really about terminology but instead it basically expands acronyms. The section does not define any terms or does it make it clear where terms are defined. A reader who does not know T-PE will not be pointed to a document that defines 'Terminating Provider Edge Node of MS-PW'. I usally find terminology sections more useful if they say where definitions of terms get be found. Section 3: s/the the/the/ Section 4: What is the 'Version' field in the message format? Section 4: There is an 8-bit field marked U C Flags and I _assume_ the U and C bits are the 'first' two bits and the 'remaining bits are the flags managed by IANA. Perhaps make this clearer, e.g.: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last Received Seq Number | Message Type |U|C| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Or alternatively simply name the entire 8-bit flags field like you do in the text where you refer to Message Flags and then explain in the text under the 'Message Flags' that the first two bits have a fixed meaning. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last Received Seq Number | Message Type | Message Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This option carries less information but then you use 'Message Flags' in several places and you also request an IANA registry for Message Flags where the U and C bit are allocated. Looking at the IANA text, it says 'bit position' 0 and 1. Not sure this is clear enough, you seem to number bits in the order 0, 1, 2, ... It turns out we have several slightly different labels further down in the document for this flags field throughout the document - this makes searching in the text difficult, please use a single consistent name for this message field. Section 8.2 says values 1 and 2 are defined in this document but then it seems value 3 is also allocated, no? Subsections of section 8 switches several times between decimal and hexadecimal numbers. Perhaps things get clearer if a single number system (e.g., hexadecimal) is used when talking about a specific registry. Numbers like 134,217,728 look somewhat confusing, 0x8000000 seems simpler.
I agree with Yaron's comment from the SecDir review. We shouldn't refer back to old security considerations sections, but rather revisit the considerations with current threats.
0) The intended scope of this protocol is not clearly specified in the Abstract or Introduction. By looking at RFC 6478, I can see that the original method (and hence the optimization) is for static pseudo-wires. However, in the introduction, it says " When PWs use a Multi Protocol Label Switched (MPLS) network as the Packet Switched Network (PSN), they are setup according to [RFC8077] static configuration mode and the PW status information is propagated using the method described in [RFC6478]." Looking at RFC8077 - I see a single line about static assignment. From reading the abstract & introduction, I cannot tell whether this technology applies to: a) statically configured PWs across a dynamically controlled PSN b) statically configured PWs across an MPLS-TP network c) any PWs across a dynamically controlled PSN d) any PWs across an MPLS-TP network I'm sure that the authors and WG have a clearly understood scoping - but it isn't obvious, even after scanning references to me. I think that it is intended for "statically configured PWs" because if LDP were used to create the PWs, there would be information about the PW status in LDP so this mechanism (optimizing the mechanism that is in RFC 6478) is only needed for statically configured PWs. 1) In Sec 2, it states "A PE using the PW status refresh reduction protocol MUST send the PW status refresh reduction Message as soon as a PW is configured on a particular LSP. " I have several questions as I think about implementing this and dig into the nuances. As it is stated, I think it has issues. a) Is the assumption that a PE will use the PW status reduction protocol for every LSP it has? Wouldn't that depend on the egress of the LSP & specifics of configuration? This MUST removes such flexibility without any discussion. b) Do you mean the PW status refresh reduction message MUST be sent as soon as the first PW is configured on an LSP? If this is for every new PW without consideration for dampening, I could see a new configuration being loaded, processed, and resulting in a flood of PW status refresh reduction messages. Surely there should be a maximum rate at least. 2) In Sec 3: "If the refresh reduction protocol session is terminated by entering the INACTIVE or STARTUP states, the PE MUST immediately re-send all the previously sent PW status messages for that particular LSP for which the session terminated. In this case the refresh timer value MUST NOT be set to zero, and MUST be set according to the local policy of the PE router." This MUST forces a flood of messages. Is there a reason that the PW status messages shouldn't be staggered out in time based upon 2x the refresh timer for PW status messages? At a minimum, something like "the PE SHOULD re-send .... as soon as possible and MUST resent them within .... interval" would be safer for the spiked load.
1) In Sec 5.2.1: "5.2.1. MPLS-TP Tunnel ID This TLV contains the MPLS-TP tunnel ID. When the configuration message is used for a particular keepalive session the MPLS-TP Tunnel ID sub-TLV MUST be sent at least once. The MPLS Tunnel ID " This is the first mention of MPLS-TP rather than MPLS and the section isn't consistent. I would assume that this is intended to be the MPLS Tunnel ID, except a reference later on is to MPLS-TP Identifiers. Looking at that, it's the same thing I'd expect for MPLS. I think that the fix here is a typo and a paragraph explaining that the same format of Tunnel ID works for MPLS and MPLS-TP and that there is no implication of this working only for MPLS-TP tunnels. Nit: a) Sec 4: "Last Received Message Sequence Number The sequence number of the last message received. In no message" should be "If no message"
S 1. Periodic retransmission of non-zero status messages, and a simple acknowledge of PW status "acknowledgement", perhaps? S 2. I found the state machine here a bit hard to follow. Some sort of diagram might help. S 4. This is kind of an odd recommendation for how to generate the session ID. Why not just Hash(timer) rather than hash of an ASCII formatted date? S 5. The C Bit is used to signal the end of PW configuration transmission. If it is set, the sending PE has finished sending all it’s current configuration information. "its" Is last received sequence number a cumulative ack or the temporarally last received packet? S 5.2 Is Length the remaining length or the length of the entire TLV?
8.3. PW Status Refresh Reduction Notification Codes IANA needs to set up a registry of "PW status refresh reduction Notification Codes". These are 32-bit values. Type value 0 through 7 are defined in this document. Type values 8 through 65536, and 134,217,729 through 4,294,967,294 are to be assigned by IANA using the "Expert Review" policy defined in RFC5226. Type values 65536 through 134,217,728, 0 and 4,294,967,295 are to be allocated using the IETF review policy defined in [RFC5226]. For each value assigned IANA should also track whether the value constitutes an error as described in Section 5.1. When values are assigned by IETF Review, the setting of this column must be documented in the RFC that requests the allocation. For Expert Review and FCFS assignments, the setting of this column must be made clear by the requester at the time of assignment. FCFS policy is not used in this document, so it shouldn't be mentioned. Or possibly you meant "IETF Review" here?
draft-ietf-dmm-lma-controlled-mag-params
I had a few minor editorial comments: "LCMPReregistrationStartTime This variable is used to set the minimum time interval **in number of seconds** before the expiry... The default value is 10 units, where each unit is 4 seconds." I understand what it is trying to say, but the "in number of seconds" and "units of 4 seconds" seemed confusing to me (and I immediately wanted to try set it to e.g 43 seconds, just because :-)) "LCMPHeartbeatInterval" SHOULD NOT be less than 30 seconds or more than 3600 -- why not? If I choose to DoS myself (or limit my ability to change), isn't that my choice? (No need to change this, just checking to make sure the numbers had discussion behind them).
In 3.1.1 and 3.1.2: I assume all 16-bit values are in Network byte order, but it would be good if the document said so. In response to Mirja's point 4: I think specifying requirements on management interfaces is appropriate using RFC 2119 language. And yes, if an option is sent on the wire, it should be configurable. But I think drawing implementor's attention to this is important.
Substantive: Security Considerations: Seems like more is needed here. Do you mean to say that none of these parameters add any security considerations that were not there for existing headers? If that's the case, please say so, and why people believe that to be the case. Editorial: - Abstract: Can you mention what sort of parameters this contemplates? (At a very high level.) - 5, 2nd paragraph: "MUST be extended " seens like a statement of fact. -- "parameters MUST be defined" Doesn't this document define them?
If text is expanded on the security considerations section from Mirja's comment (thanks for asking that), benefits of the extensions to reduce traffic should also be included.
Minor comments: 1) Please add a reference to rfc5213 right at the beginning of the intro: s/A large Proxy Mobile IPv6 (PMIPv6) deployment/A large Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployment/ 2) Section 3.1 says: "The alignment of the sub-option MUST be 4n." Is that actually (still) important? Is this also the reason for the reserved field in the option or is there an expectation that any flags will be needed in future? Could you remove the reserved field and require 6n then (given you anyway at least need the LCMP Type and Length fields)? No strong need to change anything, just asking... 3) Given that section 4 only has one subsection, I guess the subsection heading for 4.1 can simply be removed. 4) Are sections 4 and 5 updates to RFC5213? I find the use of normative language at the beginning of each section a little weird, e.g.: "The LMA MUST allow the following variables to be configured by the system management." Isn't it implicit that these things have to be configurable to implement this option? I would just not use normative language here... 5) Also section 4: I would recommend to use normative language rather to define the used values itself than what they should be configured to, e.g. OLD "It SHOULD NOT be set to less than 30 seconds or more than 3600 seconds." NEW "The delay time SHOULD NOT be less than 30 seconds or more than 3600 seconds." Maybe even use a MUST here? 6) Security consideration: Aren't there security implications if an external node can influence the number of message and therefore the network load?
draft-ietf-6man-rfc2460bis
Support Alvaro's Discuss.
I support Ekr's DISCUSS (and most of his comments should be DISCUSSes) and Alvaro's DISCUSS.
I support Ekr's DISCUSS. Otherwise, thank you for structuring this bis draft in a way where the diff tools are actually helpful.
My discuss is mainly on text in section 4.8 (also based on the tsv-art review -> Thanks Martin!): I find the recommendation to basically just not use hop-by-hop headers in section 4.8 extremely unsatisfying. Can we maybe do better? Wouldn't it be maybe time to just deprecate the current hop-by-hop number an assign a new one? I know that also has deployment problem but maybe it's worth a try. I guess the assignment could happen in a new document though, but the deprecation could be done here. This related to this comment from Martin's review, also proposing a potential way forward: "- Section 4.8. "Defining New Extension Headers and Options": It says new hop-by-hop headers must never ever defined. This is problematic, as this closing the door forever, even if future instances of the IETF do would like to wish to define new hop-by-hop headers. A better way would have to say "that new hop-by-hop headers must have IETF consensus". - Section 4.8. "Defining New Extension Headers and Options": Also the „not recommended“ to define new extension headers looks strange, especially with the phrase "There has to be a very clear justification". The term "clear justification" is not an exact engineering specification. Why not using "technical protocol specification and real word use case required, plus IETF consensus"?" As a side note, there is at least one experimental RFC that defines a destination option to be inspected by a network device, given the know problems of hop-by-hop option which renders them unusable.
One question because I'm not sure if I interpret this correct to make it part of my discuss: Section 4.5: "The number and content of the headers preceding the Fragment header of different fragments of the same original packet may differ. Whatever headers are present, preceding the Fragment header in each fragment packet, are processed when the packets arrive, prior to queueing the fragments for reassembly. Only those headers in the Offset zero fragment packet are retained in the reassembled packet." Does this mean the ECN codepoint (part of the Traffic Class field) is copied from the first fragment? This doesn't seem to be correct, however, also not sure what the correct answer is. I know this was not changed in this revision but maybe we can still get this right.
I think it is valuable and accurate to express the maturity of IPv6 by making it an Internet Standard as the transition to IPv6 accelerates.
This security considerations section seems fairly unsatisfactory. First, you can't just point back to IPv4, which doesn't even have a security considerations section. Second, IPv6 actually has different security and privacy properties than IPv4 in a number of respects, so you actually need to document them.
I get that this document is from a period before the style became as uniformly to upper-casify RFC2119 keywords, but but it seems like it might be a good idea to do that here. It's a little hard to determine what is normative here, but S 4. says A full implementation of IPv6 includes implementation of the following extension headers: Hop-by-Hop Options Fragment Destination Options Routing Authentication Encapsulating Security Payload Given that 6434-bis seems to have backed away from IPsec, this document needs to as well. S 4.4. Assuming I am reading this document correctly (and I've never implemented v6 so I could be crazy), in order to implement the routing header you need to decrement Segments Left, but the document does not seem to say that. S 4.5. As I read this document the order of headers is only strongly recommended, but the rules about fragmentation seem to absolutely require a specific order: The Per-Fragment Headers consists of the IPv6 header plus any extension headers that must be processed by nodes en route to the destination, that is, all headers up to and including the Routing header if present, else the Hop-by-Hop Options header if present, else no extension headers. Is there a reason why the rules are not MUST? S 4.5. The following conditions are not expected to occur, but are not considered errors if they do: The number and content of the headers preceding the Fragment header of different fragments of the same original packet may differ. Whatever headers are present, preceding the Fragment header in each fragment packet, are processed when the packets arrive, prior to queueing the fragments for reassembly. Only those headers in the Offset zero fragment packet are retained in the reassembled packet. If fragments follow different paths (not crazy) then the hop limit will be different, right? So perhaps "not expected" is a bit strong. S 8.4. Response packets that carry Routing headers that were derived by reversing the Routing header of the received packet IF AND ONLY IF the integrity and authenticity of the Source Address and Routing header from the received packet have been verified by the responder. It's not clear to me how this works. If, as I suggest above, the routing header gets changed in transit, how do you measure the integrity and authenticity? Even if that is not the case, and you use something like IPsec to provide integrity, why do you trust whatever claims the sender makes about routing.
First off, this DISCUSS is NOT about questioning the rough consensus calls that the responsible Chair and AD have made, or wanting to change them, but about clarifying to avoid misinterpretations. Given the ongoing discussion about Extension Headers and controlled domains (for example [1] and [2]), the text should be very specific on what is expected and where. Because it is not, I think that this document is teetering along the line of having a "high degree of technical maturity", and not being ready for Internet Standard [rfc6410]. Without further clarifications and guidance, this document also brings on unanticipated second order effects [rfc3439] that can impact the direction, or even the viability, of future work in the IETF. Specifically, a straight forward interpretation of the text in Section 4 is the absolute prohibition to process, insert or delete EHs -- but discussion on the 6man mailing list seems to point at an understanding that the conditions inside a controlled domain may be different, for example (from Brian Carpenter [3]): ===== I've tried to say this before but I'm not sure people are getting it: RFC2460bis, if approved as is, draws a line in the sand *for interoperability across the whole Internet*. There are reasons for this - PMTUD in any form, any future replacement for the unsuccessful IPsec/AH, and all the problems of deploying extension headers that are understood by some nodes and not by others. There is no reason why a subsequent standards-track document cannot allow header insertion (and removal) within finite domains where the above issues do not apply. In fact, an improved version of draft-voyer-6man-extension-header-insertion-00 could become exactly that. ===== [N.B.: I'm not implying that Brian's opinion represents consensus, that is not my call to make.] I'm pointing at an opinion (which I agree with) that recognizes the need to differentiate between contexts -- but the current text in rfc2460bis doesn't do that. I believe that this issue is significant (as reflected by the ongoing discussions) that that it should be resolved (by clarifying the text) before proceeding with the publication of this document as an Internet Standard. To summarize, the text in this document has the second order effect of not leaving a clear path forward for extensions to IPv6 so that they adhere to the protocol's architecture, specially when applied to a controlled domain. At a minimum, I would like to see a clear path forward, whether that is in the form of an update for use of extensions in controlled domains, or a statement that this document just applies to IPv6 traffic intended to cross the Internet (as suggested at the 6man meeting in Chicago [4])... My opinion is that this document should not be published as an Internet Standard until the remaining open discussions are explicitly resolved and this document reflects that resolution. [1] https://mailarchive.ietf.org/arch/msg/ipv6/UI0PfqrWco4Hpbvm8keGR8FabRg/?qid=9a6ba8e9777114e24a1e964336ed78f1 [2] https://mailarchive.ietf.org/arch/msg/ipv6/OrLYxKumiKWLHGkeNamhq9pxutQ/?qid=63c159fe41c18653d9dc0be609f9e97f [3] https://mailarchive.ietf.org/arch/msg/ipv6/REez0-lbebpo-Xem-xX_sWV0pf4/?qid=5cdab6c6085795129802ab622bb4159f [4] https://www.ietf.org/proceedings/98/minutes/minutes-98-6man-00 ========== Related to the above, I also want to point out the lack of clarity in the text in Section 4. (IPv6 Extension Headers), which leaves itself open to interpretation and should be cleaned up. (A) The main piece of text that has been discussed now reads: With one exception, extension headers are not examined, processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. Note: If an intermediate forwarding node examines an extension header for any reason, it must do so in accordance with the provisions of [RFC7045]. ... The exception referred to in the preceding paragraph is the Hop-by- Hop Options header, which carries information that may be examined and processed by every node along a packet's delivery path, including the source and destination nodes. The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header. Its presence is indicated by the value zero in the Next Header field of the IPv6 header. NOTE: While [RFC2460] required that all nodes must examine and process the Hop-by-Hop Options header, it is now expected that nodes along a packet's delivery path only examine and process the Hop-by- Hop Options header if explicitly configured to do so. While the first sentence seems clear on what this document wants forwarding nodes to do (or not), there are two notes that define exceptions: any forwarding node can examine the headers "for any reason", and, the Hop-by-Hop Options header doesn't really have to be examined and processed by everyone. This text needs some more work to at least not contradict itself: there is more than one exception, and they are not absolute, anyone can examine the headers "for any reason"... (B) As it stands, the note about the changed expectations for the Hop-by-Hop options header opens a significant door to work around the "limitations" of other options. For example, it would be relatively straight forward to define a new Hop-by-Hop option to carry any type of information that could then be "examined, processed, inserted, or deleted by any node along a packet's delivery path". In the world of controllers and programmatic access to forwarding nodes, changing the explicit configuration on the fly to customize which nodes do what, is trivial. Is that the intent of this document, to provide a generic mechanism for cases that may need extension headers to be "examined, processed, inserted, or deleted by any node along a packet's delivery path"? Will the WG/IETF be in a position to charter, adopt and/or publish these types of documents? I ask this question not only in the context of my concerns expressed above, but also because the definition of the Hop-by-Hop Option would seem to be able to handle anything ("used to carry optional information that may be examined and processed by every node along a packet's delivery path" - I didn't see any constraints), even if (for example) the Routing Header "is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination" -- so it makes me wonder whether using the Hop-by-Hop Options header to carry (for example) routing information so that it can be "examined, processed, inserted, or deleted by any node along a packet's delivery path" would pass the bar set in Section 4.8. (Defining New Extension Headers and Options): New hop-by-hop options are not recommended because nodes may be configured to ignore the Hop-by-Hop Option header, drop packets containing a hop-by-hop header, or assign packets containing a hop- by-hop header to a slow processing path. Designers considering defining new hop-by-hop options need to be aware of this likely behaviour. There has to be a very clear justification why any new hop-by-hop option is needed before it is standardized. In the context of a controlled domain, it should be relatively easy for the operator to account for those issues. So my interpretation of whether a Hop-by-Hop option is ok to carry (for example) routing information is a strong "Yes!". Whether my interpretation is what was intended or not, I believe the overall text could benefit from more clarity.
Appendix B. (Changes Since RFC2460) mentions that the text was revised based on updates from several other RFCs which Updated rfc2460. I didn't check all the details, but if the updates were incorporated in this document, why are those RFCs not marked as being Obsolete? Is there any value left in them?
Please have a look at the changes suggested in Peter's Gen-ART review: https://datatracker.ietf.org/doc/review-ietf-6man-rfc2460bis-08-genart-lc-yee-2017-02-28/
draft-ietf-dhc-relay-server-security
Thanks for producing this document, when the DISCUSSes clear :-)
Agree with other ADs' comments.
I strongly agree with Warren's discuss. This document is an update of RFC3315 and therefore MUST carry the update tag. If someone decides not to implement this new specification, they will still only confirm to RFC3315 and not this new document. As Warren said, someone who wants this encryption needs to require conformance to this new RFC anyway. However I think the IETF should give a clear recommendation here that encryption must be used. If the working group really believes there are cases where encryption is not needed, this document must be rewritten to allow for these cases (by using SHOULD/RECOMMENDED instead of MUST/REQUIRED) and give a clear recommendation when it is acceptable to not use encryption. Further, I'm also wondering why this is not just incorporated in rfc3315bis?
Thank you for writing this document. I am curious to know whether there are existing or planned implementations/deployments of this document. I am also agreeing with Warren concerns.
I am balloting "Yes", but I share the curiosity about whether people will really do this. -3, third paragraph: "MUST exchange messages securely" "Securely" is too ambiguous for a MUST. What specific protections are required? -3, paragraph 4: The list starts with no context. A sentence or paragraph describing the purpose of the list would be helpful.
This document says that it "replaces the text in RFC3315 Section 21.1.", but it does not have an Updates tag. It is also contains a large blob of RFC3315, with clear explanation of what exactly changed. The writeup says "Even though this I-D introduces changes to RFC3315, the WG doesn't want to enforce IPsec encryption on every DHCPv6 server. Therefore it does not update RFC3315." -- so, if I'm writing a new DHCPv6 implementation, do I need to support this? The document reads like it tries to update 3315, but the writeup says otherwise -- once published, no-one will read the shepherd writeup. I think that the document itself needs to be clearer that this is an optional extension (so if I want to buy an implementation which does this, I ask for RFC3315 and RFCxxxx). I also do not understand the relationship between this document (which talks about text RFC3315), and draft-ietf-dhc-rfc3315bis (which is currently in WGLC) -- if rfc3315bis is almost done, should this reference that instead? Or should rfc3315bis simply incorporate this?
I found the document confusing -- it says that it REQUIRES IPsec for DHCPv4 and DHCPv6, but it reads like it is requiring that operators enable this, not that implementations have to support this; what exactly is is trying to do? I think that it would be much clearer if it said that implementations of this document must support IPsec and that operators are recommended to enable it (assuming that it what it means).
The advantage of a late review is that everything has been said already by other ADs :-)
Thank you very much for your work on this document. Once Warren's discuss has been cleared with adequate clarifications and 'updates' text, which I support, this will be a helpful document. It will be very nice to no longer have the discussion as to why encryption is not required for DHCP, this is a welcome and overdue change. Is there an expected change to encrypt the full path in a future revision?
I agree with both Warren's discuss and Benoit's comments about balloting being easier when others have already done so :-)
What's not clear to me from reading this docment is whether anyone actually does IPsec for DHCP relaying. If so, what configurations do they run it in? If not, will they do so as the result of this document?
I agree with Warren's confusion about the relationship between this document, RFC3315 and draft-ietf-dhc-rfc3315bis.
draft-ietf-ippm-twamp-time-format
Good feedback from Jon Mitchell, in his OPS-DIR review: Indeed, TWAMP Test, and the time stamp format to be used, may be controlled by means other than TWAMP Control, e.g., local configurable knob exposed via data model or CLI. I'll work on text updates for the next version. Regards, Greg On Fri, Mar 17, 2017 at 2:01 PM, Jon Mitchell <jrmitche@puck.nether.net> wrote: Reviewer: Jon Mitchell Review result: Has Nits I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Ready with Nits - this draft adds the ability to use PTP timestamps as an alternative to NTP timestamps for active performance measurement protocols OWAMP and TWAMP. Although this draft does a good job of discussing interoperability for both sides of the session having or not having support for this operational capability, in several places it states that if a send/receiver support this capability it must be set to 1 in the flags. However, only for TWAMP Light mode, this seems configurable. This may just be my interpretation, but it probably should state that local implementations MAY provide a configurable knob to not negotiate PTPv2 timestamps in section 2.1 and 2.2 even if the capability is supported by the implementation.
Nit on the Security Considerations section. Higher resolution timestamps provide potential vehicles for side channel attacks on remote endpoints. This probably is not a huge issue, but it might be nice to mention it.
draft-ietf-alto-multi-cost
Another +1 to ekr's point on fingerprinting.
+1 on EKR's comments.
I agree with Ekr
Martin Thomson raised some good comments, that are worth a reply: https://datatracker.ietf.org/doc/review-ietf-alto-multi-cost-08-artart-telechat-thomson-2017-04-05/
Thanks for your response to the SecDir review: https://mailarchive.ietf.org/arch/msg/secdir/IeteBTg_rl9JNarNecvNAgjocZo And adding the security consideration text from Eric's discuss.
This document states: "This document does not introduce any privacy or security issues not already present in the ALTO protocol." This may be true, but it's not obvious it is, because when questions are asked together, that's more of a privacy signature than independently. So, suppose that application A asks for metric A and application B asks for metric B and application C asks for A and B. If these applications are mixed behind a CGN, with single queries then you don't know whether you have some A clients and some B clients, but if you do multi-query, it's clear these are C clients. This is a potentially serious issue if (for instance) Bittorrent always asks for a very distinguished set of parameters, so an ALTO server might use this to find Bittorrent clients. I don't think any normative change to the protocol is required here, but I do think you need to accurately characterize the situation. Something like the following text should be fine "The privacy and security properties of the mechanism specified in this document are generally similar to those already present in the ALTO protocol. However, because queries for multiple metrics represent a stronger fingerprinting signal than queries for a single metric, implementations of this protocol may leak more information about the ALTO client than would occur with a succession of individual queries; although in many cases it would already be possible to link those queries by using the source IP address or other existing information. "
I agree with the point Eric raises.
draft-ietf-isis-mi-bis
Security Considerations: Have people thought about whether multiple protocol instances changes anything? If so, please consider documenting those thoughts here.
I agree with the SecDir reviewer and would like to see clarifying text added as requested. https://mailarchive.ietf.org/arch/msg/secdir/whfo-cclZqRopq5rb64lARkYdOc
draft-ietf-httpbis-encryption-encoding
section 3.1: "plaintext = SSBhbSB0aGUgd2FscnVzAg" ?
Thanks for addressing the SecDir review comments: https://mailarchive.ietf.org/arch/msg/secdir/6TCbjRD3sEBNmZxEhxN7Q4LA0aI
Thanks for producing this specification.
The "aes128gcm" content coding uses a fixed record size. The final encoding consists of a header (see Section 2.1) and zero or more fixed size encrypted records; the final record can be smaller than the record size. This restriction seems to be an artifact of your previous design which used short records as an end marker. With the new padding delimeter structure (which I note is isomorphic to the TLS 1.3 structure), I'm not seeing any reason to require that the records be fixed length (as they are not in TLS). I didn't see any discussion of this point in the thread where this structure was designed, so I'd like to get confirmation that the WG considered this point and decided to continue with the above restriction. I'll clear this discuss upon either such confirmation or removal of the restriction.
S 2.1. You should say what idlen is. The QUIC notation here isn't defined :) S 2.2/2.3. Can you make clearer that the strings don't have their own null termination. I.e, that what is fed into the CEK generation function is .... 32 38 67 63 6d 00 01 not .... 32 38 67 63 6d 00 00 01 S 4.6. This mechanism only offers encryption of content; it does not perform authentication or authorization, which still needs to be performed (e.g., by HTTP authentication [RFC7235]). This text is kind of confusing, because the mechanism does provide data origin authentication. I think you mean that if the server is just going to process this as an opaque and stuff it somewhere, then it needs extra authentication? This seems like a layering issue. S 4.7. Some citations to some of the various padding traffic analysis papers might be useful. Distributing non-padding data is recommended to avoid leaking size information. I think you mean "distributing this across the records".
From Pete's Gen-ART review: Nits/editorial comments: Looks fine from a non-security-expert's perspective. It is my duty to ask about keyid in section 2.1: A "keyid" parameter SHOULD be a UTF-8 [RFC3629] encoded string, particularly where the identifier might need to appear in a textual form. I presume that simply means "might need to be rendered" and does not include "might need to be typed in by someone", correct? The former is easy; the latter probably requires a bit more text.
draft-ietf-isis-auto-conf
Thanks for this.
* Section 3.3. The TLV format seems to be off. Why does there seem to be a two octet gap between the Type and Length fields and the Flags field. I think the flag field needs to be pulled forward to bit 16 and the Router fingerprint to bit 24. Also agree with Alvaro's comments.
I am agreeing with Alvaro's comments.
-4: "In general, the use of authentication is incompatible with auto- configuration as it requires some manual configuration." What are the consequences/risks due to that incompatibility?
Some editorial comments: page 3: > It SHOULD not be changed due to device status change (such as interface > enable/disable, interface plug in/off, device reboot, firmware update etc.) The term “due to” is confusing. It might be change to “It SHOULD not be changed until the device status change” or “It SHOULD not be changed as the device status change” according to the meaning. Page 8 > As specified in this document, there are two distinguisher need to be > self-generated, which is System ID and Router-Fingerprint. s/which is/which are Page 9 > In a network device, normally there are resources which provide an > extremely high probability of uniqueness thus could be used as seeds to > derive distinguisher (e.g. hashing or generating pseudo-random numbers), > such as: Suggest to split the sentence to make it more readable.
Thanks for your response and updates to the SecDir review. https://mailarchive.ietf.org/arch/msg/secdir/_DxRs_eINTVE8E-N3S31Zr_10B8 I don't see any privacy considerations with the identifiers created, discussed in System ID and Router-Fingerprint Generation Considerations and Section 3.2. Are they in later documents that use these identifiers? I see they may not be unique in home networks, but are there considerations for how they might be used that need to be documented? Thanks in advance.
COMMENT I am having trouble reconciling 3.4.4 and 3.4.6. 3.4.4 seems to tell us how to handle the situation where both System-Id and Router-Fingerprint are identical: If the fingerprints are identical in both content and length (and state of the S bit is identical) and the duplication is detected in hellos then the both routers MUST generate a new System ID and restart the protocol. And then 3.4.6 says: Also note that the conditions for detecting duplicate System ID will NOT be satisfied because both the System ID and the Router- Fingerprint will be identical. So, I am confused. "entropy" is already a collective noun, so I think if you want to pluralize it, you need to say "sources of entropy" I am surprised that you are recommending HMAC-MD5, but I guess that's how IS-IS rolls?
I have a series of comments -- they don't add up to a DISCUSS, but I think it is important that they are solved before publication. (1) In Section 3.3. (Router-Fingerprint TLV), the format presented doesn't actually show the "flags field", which is described in the text, but it shows its contents. The length is defined as "the length of the value field", but the figure doesn't explicitly show the Value field. It is probably obvious that the flags field + Router Fingerprint = Value, but it would be nice to be specific. Suggestion: include the 1 octet "flags field" in the drawing -- if needed, then show the detail (where the S and A bits are) in the description of the field. (2) What about the other bits in the Flag field, how should they be registered in the future (if needed)? Please ask IANA to define a registry for them. (3) Section 3.1. (IS-IS Default Configuration) mentions several TLVs that MUST NOT be used...and Section 3.3. (Router-Fingerprint TLV) says that this TLV MUST NOT be included in an LSP with a non-zero LSP number. What should a receiving node do if any of those conditions are not true? (4) s/3.4.3. IS-IS System ID Duplication Detection and Resolution/3.4.3. IS-IS System ID Duplication Detection (5) I thought the point of this document was for use in "unmanaged deployments. It allows IS-IS to be used without the need for any configuration by the user." But Section 3.5. (Additional IS-IS TLVs Usage Guidelines) has recommendations for configuration options, including manually configured adjacencies (which should not be allowed according to Section 3.4.2. (Adjacency Formation)). Isn't this against the stated reasons for this document? (6) Authentication is one of those features that could be manually configured -- but the default is no authentication. There's a higher-than-usual risk of a node listening on the network (probably a bigger problem for the user traffic), but also one that could listen to the Hellos and purposefully trigger the duplicate resolution mechanism to continuously run. This risk should be highlighted in the Security Considerations because it is newly introduced here. [Robert Sparks pointed this risk out during his GenArt review.]
Small comment: section 3.4.2.: "Routers operating in auto-configuration mode MUST NOT form adjacencies with routers which are NOT operating in auto-configuration mode." It's not fully clear to me which actions will follow in this case... abort start-up/configuration and log an error?
Thank you for addressing the point raised in the Gen-ART review.
status-change-icmpv6-dns-ipv6-to-internet-standard
I agree that two independent requests would be clearer but as long as noone has an objection against one of them, I guess it's fine.
I was alsoconfused by the two-in-one request, but there is no point in changing it now.
I have no objection in changing the state -- it might have been a little cleaner to change them separately (in independent actions) since they don't seem to depend on each other. The change text mentions RFC3595 instead of RFC3596.
draft-ietf-aqm-codel
I think that this is a useful document - I also think that it would make a good introductory document to describe queuing for e.g a collage class. I do have some readability suggestions to make it even better; these do not need any action, but if the authors happen to edit the document for any other reason, they may want to address them. 1: I found the overall structure of the document a little odd -- I'm assuming that this is an artifact of its history, or merging multiple documents into one, or similar. It starts off with a nice description of queuing and CoDel. It then gets all technical with the pseudo-code (which was really helpful). Where it feels a little odd is that it then suddenly goes back to being much more introductory feeling (Section 5 - ), and feels like it repeats some of the earlier material. Reformatting it all to address this seems like overkill, but perhaps a readers note to suggest people who want more background should skip ahead then come back. 2: Section 1. Introduction - "determined set point derived from maximizing the network power metric" -- I'd suggest referencing Section 5.2 where power is explained (or, if we assume readers understand this, section 5.2 can be dropped). 3: Section 3. Overview of the Codel AQM Sojourn time is a really important concept in this document, but it isn't really defined - Section 5.1 is closest to defining it, but still not great. 4: Section 3.1 "The MTU size can be set adaptively to the largest packet seen so far or can be read from the driver." It was unclear what driver -- perhaps "interface driver" or simply "interface"? 5: Section 3.2 has an opening parens but no closing one ("known or measure (though ..."). This is a tiny nit, but set off my OCD tendencies :-) 6: Section 5.1 "We use this insight in the pseudo-code for CoDel later in the draft.) - earlier in the draft... Section 5.2: AIMD TCP could use a reference.
Same view as Warren point 1. I just wondered: why this section 5 as that position? 1: I found the overall structure of the document a little odd -- I'm assuming that this is an artifact of its history, or merging multiple documents into one, or similar. It starts off with a nice description of queuing and CoDel. It then gets all technical with the pseudo-code (which was really helpful). Where it feels a little odd is that it then suddenly goes back to being much more introductory feeling (Section 5 - ), and feels like it repeats some of the earlier material. Reformatting it all to address this seems like overkill, but perhaps a readers note to suggest people who want more background should skip ahead then come back.
Thank you for a clear and very well written document. This was well worth staying up past 1am to read fully. I do have one primary comment and a couple minor points. First, the document status is Experimental. While encouraging experimentation, the document doesn't really articulate what the concerns are or how experimentation might determine that this should be changed to standards track. While regrettably I haven't personally followed the AQM work, I might assume that some of the issues to general applicability might be tied to aspects around the challenges of applying CoDel to a system architecture built around WRED AQM and enqueue complexity rather than dequeue complexity. Having a paragraph that gave context in the introduction for the questions still to be explored would be helpful. a) In Sec 3.4 : "This property of CoDel has been exploited in fq_codel [FQ-CODEL-ID], which hashes on the packet header fields to determine a specific bin, or sub-queue, for each five-tuple flow," For the general case of traffic, it would be better to focus on using a microflow's entropy information - whether that is derived from a 5-tuple, the IPv6 flow label, an MPLS Entropy label, etc. Tying this specifically to the 5-tuple is not ideal. Obviously I missed this for draft-ietf-aqm-fq-codel-06 - but even a slight rephrasing to "for each microflow, identifiable via five-tuple hash, src/dest + IPv6 flow label, or other entropy information" would encourage better understanding of micro-flow identification. Of course, this is just a comment - so do with it what you will. b) (Nit) In Sec 5.1: " We use this insight in the pseudo-code for CoDel later in the draft." The pseudo-code is actually earlier in the draft. Also s/draft/document for publication.
The normative part of this document seems reasonably clear and I believe I could implement it. Note: I have not attempted to assess the technical quality of the algorithm described in this protocol. I found the descriptive part a little hard to follow in places. Specifically: - It's a little hard to work out which things are informal terms and which are defined terms of art. "power" is used first on page 4 but it's only clear that it's a term of art in S 16. This could be fixed by a forward reference and a cite to Kleinrock. "target" and "interval" are constants in the algorithm, but this wasn't entirely clear to me in S 3.2. You could deal with this by stating in S 3 that the algorithm takes in two variables (TARGET and INTERVAL). Perhaps capitalize them. I see you also use "setpoint" and "target" and "target setpoint". I would stick to one if you can. - It seems that the document went through some reordering because S 5.1. refers to the pseudo-code as coming later in the draft. Perhaps some of the rationale could come before the pseudo-code. Specifically, the intuition that the dropping happens only when you are able to send packets (dequeue) is kind of counter-intuitive. - Following up on the above point, you must be able to drop packets when the queue is entirely full, but S 4.4 doesn't seem to contemplate this. What is the impact of this? You just drop and ignore? Finally, you seem a bit inconsistent about whether you are capitalizing 2119 terms (see for instance the use of should vs. SHOULD in the second graf of S 3.2).
Glad to see this document progress. From Fernando's Gen-ART review: * Page 17: simulation that this result holds for Reno, Cubic, and Westwood[TSV84]. Missing space.
draft-mm-wg-effect-encrypt
While I support the draft's intention to document current network management tools to help the community going forward with protocol development, considering the recent list discussion, I think a much stronger statement/better tone is needed to assure the reader that operators are not against RFC7258. Privacy concerns are critical to both users and operators. It's not encryption that is evil. Operators themselves are very aware that their methods used in a pre-encrypted era may be used by "bad actors" and so the methods themselves are becoming more complex to manage in today's bad-actor world. And the use of encryption is not blindly recommended by IETF with disregard for network operations. RFC7258, RFC7435, and other documents discussed network management issues and use of encryption. And there's been an IAB workshop on managing radio networks in an encrypted world. Suggest: In the abstract, the first sentence "Increased use of encryption impacts operations" sets a negative tone "operators vs. IETF and privacy advocates". It infers IETF disregarded operational impacts in recommending encryption. I think it would be good to "set the stage" differently, adding more on RFC7258 and why encryption is needed in today's world, e.g.: "Pervasive Monitoring (PM) attacks on the privacy of Internet users is of serious concern to both the user and operator community. RFC7258 discussed the critical need to protect users' privacy when developing IETF specifications and also recognized making networks unmanageable to mitigate PM is not an acceptable outcome, an appropriate balance is needed. This document discusses current security and network management practices that may be impacted by the shift to increased use of encryption to help guide protocol development in support of manageable, secure networks." As Warren mentioned, the document "sells" the many capabilities possible when not using encryption and in some items even argues (2.3.1) that encryption is not a "panacea". This tone is unnecessarily negative - are the draft's motives to help us understand operational concerns or to argue that encryption is no better as there are always corner cases? It would be more fair if it also mentioned the well-known security tradeoffs when not using encryption. I think the document would be better perceived if it scoped itself to management issues vs. business motivations e.g. 2.3.2.1 on caching. Statements saying encryption is used for "intentional control" by the user, and not privacy motivated, are not within the scope of IETF. And, it infers any/all encryption is evil. This is an important document, let's get it right. I think in its current state, it will confuse the industry. I don't think we need to rush to publish this document.
I believe that the discussions have made the document substantially better, especially regarding its purpose. I think that it is very useful that we know how ubiquitous encryption impacts operators - not so that we stop pushing for this, but rather so that we can understand what information operators actually *need* to operate their networks -- if we make this information unavailable, operators may hinder or thwart deployment of new protocols / technologies. Having an adversarial relationship with operators doesn't end well for any of us, but collaboration might...
* Section 2 This text is a bit confusing. Who does the second "providers" refer to? The application service providers or the network service providers? If it is the latter the examples seem to be off. If it is the former, I am not sure this is relevant in this section. Following the Snowden revelations, application service providers responded by encrypting traffic between their data centers to prevent passive monitoring from taking place unbeknownst to the providers (Yahoo, Google, etc.). * Section 2.1.4. This text below is not entirely true. There are other mechanisms by which the user traffic can be separated without DPI (e.g. dedicated bearers have existed for a very long time to separate traffic). "Ideally, the scheduler manages the queue so that each user has an acceptable experience as conditions vary, but the traffic type has been required to be known to date." * Section 2.1.7.2 Since there is some sort of prior arrangement for this zero rating can't this be done by getting a list of IP addresses? * Section 3.2.1. Wouldn't server side logs and/or 5 tuple be enough to make these metrics work especially for managed applications (e.g. correlate managed application to ip address and port and then use 5 tuple on packet)? * Section 4.1.1. In at least some of the enterprises I have seen, the security enforcement is seen at the endpoints for the company owned devices. There are also new endpoint security solutions being enforced in BYOD environments (e.g. VMware Airwatch). This section seems to gloss over the fact. * Section 5.6. The SLAAC reference is wrong. Must be RFC4862 instead of RFC4682. The SEND reference is wrong. Must be RFC3971 instead of RFC3791. * Section 11 This section seems to be a grab bag of claims some of which seem to be dodgy. e.g. the ANDSF claim in Section 11.2. The ANDSF assists the UE (the endpoint) and provides rules to the endpoint. It is unclear how transport encryption will affect these rules.
This document is not perfect, but I found it to be generally useful. DMARC should probably be mentioned in Section 5.1.
I support all points of Alissa's discuss on version 10 if this is to be published as an IETF consensus document. (Does it need to be a consensus document to add value?) I think it would also be helpful to clarify the provider end-goals for each practice. That's clear in some cases, but not in all. It would also help to distinguish between situations where said goal can no longer be accomplished in the face of encryption, vs situations where the goal can be achieved by other means. Again, this is clear in some cases, but not all.
Thank you for this OPS/SEC document. This is an important document. I do NOT read this document as: encryption makes live harder for operators, so we should not do encryption. I read this document as: encryption makes live harder for operators and we should find different ways to manage networks, if possible. The point is not to do a value judgment on the "management" function (ex: HTTP header insertion) Some sentences might be expressed in a different tone, to respect the different susceptibilities (But in the end, the draft mentions facts). Ex: The loss of access to these fields may prompt undesirable security practices in order to gain access to the fields in unencrypted data flows. Ex: Effect of Pervasive Encryption => Effect of Pervasive Encryption on Operators Ex: It will take time to devise alternate approaches to achieve similar goals. => Well, not all goals described here are valid. The draft could be reorganized to make easier to read (as Christian Huitema mentioned), but that's a huge change at this point. Finally, I'm surprised not to see a section on Flow Monitoring with IPFIX/NetFlow.
We have a few small nits queued up - the two from idnits Badri Subramanyan's name will be added to the ACKs and Section 2.1.6.2 needs a small typo correction 2. Further contenty may not s/contenty/content/
First, thank you very much for handling my previous comments. Second, having reread the new version of the document, I am quite concerned that the focused efforts to deny negative impact from pervasive encryption is close to biasing the document. I am aware that there are different aspects of tussle here - ranging from the standard trade-offs between network management and privacy/efficiency/etc. to whether the application layer is the only one that can look at user-data or whether there are reasons why a network operator needs to for manageability or to profit (just as the applications do) to absolutism on the technical purity of pervasive encryption being the only true way and all concerns of collateral damage are to be ignored. There are trade-offs here - as in everything engineering - and IMHO, we need to be approaching this document as a good way of describing one part of the equation. If VoIP calls don't work with acceptable QoE because the flows aren't identifiable and given the needed QoS treatment, then having the call be private isn't particularly useful. If operators block encrypted protocols because they can't handle the costs of the call volume to troubleshoot, then no one has won. This is a really useful and excellent list of issues and concerns - and anyone who isn't terrified by the list of items that amount to "hope applications provide better logs because that's all we'll have for troubleshooting" should take a few more minutes to think it over and explain, if they are in the applications space, how they will approach solving these problems. a) "Reduces the benefits IP/DSCP-based transit network delivery optimizations; since the multiple applications are multiplexed within the same 5-tuple transport connection; a reasonable assumption is that the DSCP markings would be withheld from the outer IP header to further obscure which packets belong to each application flow." This doesn't mention the trust issue between the network and the application around DSCP markings. Even if the application does mark each application flow as to its type, without either a cost to the application or a way for the network to verify, everything could simply be marked to be Expedited Forwarding. Beyond that is the issue that different networks use different DSCP values for different purposes; how does the network tell the application which values to use?
I do not believe that this document represents IETF Consensus, largely for the reasons indicated by Martin Thomson and Christian Huitema on the IETF list recently. Specifically, this document, while perhaps not saying anything actually false, essentially only presents the perspective of operators and service providers. In many cases, those interests are adverse to those of users -- and in many cases encryption is used specifically to prevent operators from providing the "services" and "enhancements" contemplated by this document. For these reasons, I don't believe that the uncritical treamtent of these activities presented in this document should be published as an RFC that claims to have IETF Consensus. I have made specific comments below that indicate some of the more serious issues, but the problems here are systematic and require more than simple edits. S 1. draft includes a collection of current security and network management functions The functions presented here in many cases go far beyond security and management. For instance, header enrichment is neither, except by stretching the definition of "management" to breaking. S 2. middle boxes were in use to perform functions that range from load balancing techniques to monitoring for attacks or enabling "lawful intercept", such that described in [ETSI101331] and [CALEA] in the US. I'm not sure why you are mentioning CALEA here. As far as I can tell, the CALEA requirements only apply to carriers who have access to the keying material. The loss of access to these fields may prompt undesirable security practices in order to gain access to the fields in unencrypted data flows. As Martin Thomson indicates, this feels like a threat. S 2.1. As Martin and Christian indicate, this QUIC material is entirely speculative and extremely controversial and you should remove it. Additionally, a system that is able to encode the identity of the pool server in plain text information available in each incoming packet is able to provide stateless load balancing. This doesn't have to be in plaintext because the pool load balancer has a relationship with the servers. We already have designs for this for QIC. Current protocols, such as TCP, allow the development of stateless integrated load balancers by availing such load balancers of additional plain text information in client-to-server packets. (In case of TCP, such information can be encoded by having server- generated sequence numbers, mss values, lengths of the packet sent, etc.) How does this help the load balancer direct traffic. S 2.2. Internet traffic surveys are useful in many well-intentioned "Well-intentioned" is pretty tendentious here. pursuits, such as CAIDA data [CAIDA] and SP network design and optimization. I'd be interested in hearing which CAIDA studies are impacted by content encryption. Do you have citations? S 2.3.2.1. There are two kinds of caching potentially in play: - Explicit caches - Intercepting caches At this point, what ISPs primarily run is intercepting caches, and there's a lot of evidence that they contribute to bustage and ossification, as well as being a primary tool for ISPs to use to mess with people's traffic in ways that users clearly don't want (ad/tracking injection, etc.). So, I don't think an IETF consensus document should suggest that we are sad to be breaking them. S 2.3.2.2. The presentation here seems biased given that it does not acknowledge that one of the primary reasons that ISPs do traffic class discrimination is to prioritize favored rather than disfavored traffic, regardless of user preferences. I don't believe that the IETF has taken a position for net neutrality, but I'm also pretty sure we don't have consensus against it. S 2.5.3. Currently, the mobile network service provider redirects the customer using HTTP redirect to a page which educates the customer on the reason for the blockage and provide steps to proceed. Once the HTTP header and content are encrypted, the Mobile carrier loses the option to intercept the traffic and perform an HTTP redirect. With current solution options, this leaves only the option to block the customer’s request and cause a bad customer experience until the blocking reason can be conveyed by some other means. This is pretty tendentious. It's not at all clear to me that the customer thinks that having their traffic intercepted is a better experience. S 2.6.2. Zero-rating is absolutely possible in the face of encryption. Facebook Free Basics supports this. https://info.internet.org/en/blog/2015/09/24/enhancing-security-and-privacy-of-free-basics/ S 2.6.5. Header insertion is also used for tracking and advertising. S 2.7. This should be clearer about the impact of encryption at various layers. Most of the things you want to do here will work fine with HTTPS. S 2.8. When utilizing increased encryption, application server operators should expect to be called upon more frequently to diagnose problems Why would this be true? As far as I can tell, pretty much only if they are screwing with the traffic in ways that the user would prefer they not. S 3.3.1. The general monitoring needs for data replication are described in this subsection. It's not at all obvious these are needs. S 4.1.1. A lot of these monitoring applications could also be characterized as the employer conducting surveillance on its employees. S 4.2. As far as I know, the MITM techniques used by middleboxes are not described in 7457. You also need to cover the fact that these MITM are a threat to user security because they are often so badly implemented. Restrictions on traffic to approved sites: Web proxies are sometimes used to filter traffic, allowing only access to well-known sites found to be legitimate and free of malware on last check by a proxy service company. This type of restriction is usually not noticeable in a corporate setting, but may be to those in research who are unable to access colleague’s individual sites or new web sites that have not yet been screened. I'm not sure why this would be not noticeable in a corporate setting. I, for one, notice it on airplanes. S 5.3. It's pretty odd to talk about phishing without acknowledging that by far the largest anti-phishing platform (Safe Browsing) operates in the client, not be network interception. S 7.1 This entire section is pretty confusing. Issues include: - There is real debate about whether performance-enhancing proxies really work (see Mathis's comments at IETF). - Content replication needs a lot more than just being able to see ACKs. - "trusted" proxies? Trusted by who? This whole architectural structure of having invisible proxies messing with the transport stream is a total violation of the E2E argument, so I don't see how one could think that describing it as if it were positive can have IETF consensus. I also notice that this section and the sectoin below describe things that a lot of users don't want as "features" S 7.3. Content/Application based Prioritization of Over-the-Top (OTT) services - each application-type or service has different delay/loss/throughput expectations, and each type of stream will be unknown to an edge device if encrypted; this impedes dynamic- QoS adaptation. I think there's a lot of debate about whether we *want* networks to try to accommodate new traffic classes. This has lead to a lot of problems under the heading of "ossification" While CDNs that de-encrypt flows or split-connection proxy (similar to split-tcp) could be deployed closer to the edges to reduce control loop RTT, with transport header encryption, such CDNs perform optimization functions only for partner client flows; thus content from Small-Medium Businesses (SMBs) would not get such CDN benefits. Huh? Lots of SMBs use this kind of CDN. That's how e.g., Cloudflare works. Heck the IETF uses it. S 8. In the best case scenario, engineers and other innovators would work to solve the problems at hand in new ways rather than prevent the use of encryption. It will take time to devise alternate approaches to achieve similar goals. Much of the context of this debate is about whether operators not being able to do the things in this document is a problem. It is well known that national surveillance programs monitor traffic for terrorism [JNSLP] I concur with Martin's objection to the use of the loaded word "terrorism" here. Given RFC 2804 and the IETF's clear position on protocol design, this discussion of balance between surveillance and user security seems completely outside the IETF consensus. Open questions: As the use of encryption increases, does passive monitoring become limited to metadata analysis? What metadata should be left in protocols as they evolve to also protect users privacy? Huh? Coming as this does in the context of surveillance, 2804 is clear. It might be the case that there are good reasons to avoid encrypting metadata for the purposes of network monitoring by carriers, but I think the IETF consensus is clearly not to do so to enable surveillance.
- There are unresolved and substantive Last Call comments which the document does not address. For example, I have a hard time reading "Not at all" as effectively addressing concerns that the document implicitly weakens the critically important principles that RFC 7258 lays down. While feedback to improve this specific situation has been solicited from Martin, it has been scantly more than a day since that request has been made. I don't think we're in a position to move the document forward with the current slate of unresolved Last Call comments. - The IETF as a whole does not have consensus on the document. For a document with such wide-reaching remit -- spanning network layers 3 through 7 -- the IETF-wide discussion has garnered an unclear mix of support and objection, and at fairly low volume (once we discount personnel directly involved in the progression of the document). If I count correctly, we have support for a document that fills this niche from Badri and Elliot, the most tepid statement of support I've seen in quite a while from Stuart (which itself concedes that the document diverges in tone and content from prior IETF statements on related topics), and rather strong statements of opposition from Martin and Christian. The objections by both Martin and Christian are substantive and structural; and many of the primary concerns they express appear to remain unresolved. I understand the temptation to dismiss many of the objecting comments about structure and tone as editorial in nature; but this document lands squarely in the middle of a policy area in which the IETF (and the IAB in particular) has written extensively and carefully, in at least RFCs 1984, 2804, 7258, and 7754, among probably others that escape my notice at the moment; and this also includes IAB statements on the topic, such as <https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/>. Due to this factor, I believe that obtaining IETF consensus on tone rather than merely technical content is warranted in this case. ____ Addendum: Some of the documents that "escape[d] my notice" above include RFCs 1958 and 3724 (and in particular sections 4.1.1 and 4.1.2 of the latter document).
I share many of the concerns raised by Martin and Christian myself, in particular those that pertain to implicit endorsement of behaviors that other documents explicitly deprecate. I understand that the goal here is to be neutral in the way the document presents these topics (and I don't believe the current form achieves even that), but I believe that's the wrong goal. To be clear, I don't want to pretend that these techniques don't exist in the wild, but I think the current formulation (and section 2 in particular) casts certain third-party entities as "victims of encryption"; when, in fact, most of these behaviors have been proscribed by IETF protocols and architecture documents for years. This is especially salient in light of the fact that such proscription has typically been precisely for the reason that these behaviors presume that traffic behavior can never evolve (e.g. that there will never be an increase in the use of encryption), and that behavior is now finally evolving. The RFCs I cite in my discuss actually do stake out specific policy positions that pertain to overall Internet architecture; and, while I don't expect this document to necessarily reiterate all of them, it should at least be consistent with them. In the context of the clear statements made by these policy documents, much of the text of the current document reads as an attempt to pussyfoot around sensibilities of entities who may not agree with established and published IETF consensus; but that should not be the goal (even if much of the target audience of this document includes such entities). We have published statements that many of the behaviors described in this document are *not* neutral, and attempting to *treat* them in a neutral fashion is explicitly going against that consensus. To be clear: yes, I am suggesting that description, in this document, of behaviors that are discouraged by the documents I cite above should be accompanied by clearer disclaimers that they are, and have historically been, considered by the IETF to be fundamentally detrimental. I read some of the comments so far on this draft as wanting to revise the direction the IETF takes on these topics. That's a far broader conversation than pertains to this document; if we want to discuss that, I think we need to halt processing this document entirely and engage the IAB in a conversation around whether the aforementioned policy documents got it wrong. _____ Some nuts and bolts of lesser consequence: I think I've seen some messages about the potentially adversarial relationships that can arise in three- (or more) party communications, which is highly relevant; however, the document doesn't appear to have any treatment of this issue. In particular, I believe that the increased use of encryption may arise *because* of the behaviors being described, rather than despite them. I agree with Ben's comment that the document suffers from explaining what is being done rather than why it is being done in some places. Ostensibly, a major part of the document's purpose is to foster discussion about how network operators can continue to manage their network in the face of encryption; but it will be difficult to discuss alternative approaches to meet their goals if those goals are not explained. Section 2.3.2.1 mentions CDNs in a way that I find very confusing. Typically, CDNs are operated by or in cooperation with the entities providing authoritative content. Those entities are ostensibly both (a) the parties impacted by encryption, and (b) the parties choosing whether to use encryption. Clearly this can't be what you meant, since that reduces to a "doctor, it hurts when I do this" situation. I think a better description of the CDN scenario in this section is called for, if it is retained. Section 2.4 describes "undesirable security practices" in generic terms. At least for browsers (the cited application), it's not clear to me precisely what kind of practices are being alluded to. Please add an example of one such practice. In section 2.5.1, the statement mentioning "were contributed" has no context. I suspect an earlier document spoke of some process by which use cases were gathered from interested parties? I think the scenario described in section 2.5.3 does not match the scope of this document (encryption). The problem being described is introduced by authentication of servers, not by encryption of content. I suggest either removing the scenario, or expanding the scope of the document to include problems introduced by authentication. Section 2.6.1's assertions of a problem arising from encryption seem circular. It can be summarized as: the problem that arises from traffic being encrypted is that some traffic is not encrypted. This should be removed or clarified. This same tautology appears in section 3.1. In section 2.6.5, the reference to non-CPNI data is using a really obscure and technically precise term, and really calls for a definition inline. Section 2.7 discusses a number of problems that could arise from IP-level encryption, but which don't arise with the encryption that is commonly used on the Internet today. For example, analysis of TCP options, congestion window, etc. are not precluded by the use of TLS (as TCP information is sent in the clear); and the use of SRTP does not preclude analysis of VoIP traffic, as SRTP sends all the information used by DPI boxes in plaintext. As this document seems to be focusing on the practical effects of today's encryption deployment rather than the theoretical impacts of future widespread IPSEC deployment, these should probably be removed or heavily qualified. (n.b. -- I am not intimately familiar with the current level of IPSEC deployment in the Internet at large for typical large-scale consumer applications, and may be operating from an outdated view of its likely impact) I'm not sure the mention of websockets in Section 2.7 is helpful: using HTTP for the types of operations cited has been a widely-used part of web browser behavior since the introduction of XMLHttpRequest over a decade ago. I think this would be improved if mention of Websockets were dropped entirely, and the paragraph were merely cast as the increase in use of port 443 for things other than simple web page retrieval. Section 3.1.2 is very confusing -- it's muddy about which encryption here is desired by SPs, which encryption is posing novel challenges for them, and how they interact with each other. I think what's being described is a scenario in which an HTTPS connection is being terminated on a front end that can authenticate as the expected domain, decrypt the content, and then turn around and re-encrypt it. It's really not clear how this is impacted by the increased deployment of encryption, since the scenario only arises when encryption is required by the SP. I'm not the expert here, but I think I've heard that there's some thinking around how to close the "SNI Hole," so it's probably relevant and useful to mention that this technique's days may be numbered as well. Section 6.3 should probably mention the issues discussed in RFC 6562, including in particular the guidance in section 5 of that document. This issue may be true to some degree for video codecs as well, where the volume of encrypted data can be used to infer the amount of motion in a frame.
Why is section 11 in the appendix only? I would see this as an important part of the document because it seems to me that mobile operators are the ones most impacted by encryption.
I would be a 'Yes' because I think this document is very valuable, however, I think it could be structured better to provide more value. The document is rather long and has some redundancy due to the structure: while sections 2.-4. are split based on the type of network operator, sections 5. and 6. are split based on the protocol layer. Further I think section 2 could be further extended because there are more cases to cover, also see (section 3 of) https://tools.ietf.org/html/draft-dolson-plus-middlebox-benefits-03. See for more concrete and mostly editorial comments below: 1) sec 2.1.1: "The definition of a flow will be based on a combination of header fields, often as many as five for 5-tuple flows (including addresses and ports for source and destination, and one additional field such as the DSCP or other priority marking)." Usually the 5th field is the protocol number; I'm not aware of any load balancers that look at DSCP...? 2) sec 2.1.4 seems to cover two different cases: caching and differential treatment 3) sec 2.1.6. should probably be called "Content Filtering" and "Mobility Middlebox Content Filtering" should be an own subsection, as parental filtering is not specific to mobile networks. 4) I don't really understand why sec 2.1.7 "Access and Policy Enforcement" is a subsection of 2.1 "Middlebox Monitoring". Was that on purpose or an error? Actually I don't really understand the structure of section 2 at all. What's the difference between 2.1 and 2.2? I would group section 2.1.1, 2.1.2, and 2.1.3 under Traffic Monitoring and move all other subsections of 2.1 one level up... 5) sec 3 rather describes how encryption is already used and doesn't not really discuss any effects of increased use of encryption. 6) there is quite some overlap between section 2 and 4.1.3. as the problems on monitoring/troubleshoot are the same for enterprise network and other networks; the only difference is that in enterprises TLS interception may be acceptable while it's not for network operators. However, it would still be good to better align these sections. 7) section 6 only describes with information is visible but not how and if this information is used and what would happen if this information would go away. 8) section 7 should be integrated in the introduction because it sets the context for this document and it's not needed to have read the rest of the document to understand this section.
I have cleared my original DISCUSS point from my earlier review -- I get what the text is saying now, although I still think the "lose the option" language implies some entitlement to the option in the first place, which seems inappropriate. But given the reviews from Martin Thomson and Christian Huitema, it's not clear to me that this document represents the consensus view of the IETF community. Kathleen's response to Martin reinforces the point that we were discussing in the first ballot cycle, which is that this document is written for and represents operators, not the broader array of Internet interests. Yet the suggestion to state that fact up front in the document was not adopted. Having had some more time to review this document than I had in the previous ballot cycle, I also am finding myself in agreement with significant portions of the reviews from Martin and Christian. Reading their reviews helped crystallize a lot of the difficulty I had in parsing this document the first time around. I understand the rationale that led to this document being written and I think there is a version of this document that could be written that would achieve the original goals while giving the subject matter a readable, neutral treatment. Such a version would be a useful contribution. But I don't think this document achieves that. In particular, there are four things that I think it would need to do to achieve that: 1. State the analysis in a neutral way. As I had mentioned in one of the email threads for the previous ballot cycle, I believe this document could be written in a neutral way -- e.g., “Service providers currently do X. It is implemented using Y mechanism. Encryption at Z layer breaks current implementations.” -- but it is not. Instead it characterizes many of the practices described as "optimizations" or "features" or "enrichment" and states service providers' claims about what these practices accomplish (e.g., "maximize QOE") as facts rather than stating them as the reasons given by service providers for why they engage in the practices. This is why in the previous round I suggested the disclaimer at the top of the document to say that the document is giving a view from service providers; that apparently didn't go anywhere, so the other option is to describe each technique neutrally, or explain with each technique that the characterization of the benefits is from the view of the operator. Martin's comments about being clear about who is benefitting point this out as well. 2. Limit the discussion to techniques presently being affected and those effects. There is a bunch of extemporizing about future possible impacts (e.g., in Sec. 2.7, 4.1.2, 4.1.3.1, 5.7, 7, 8). It's very hard to characterize future implications, who will bear the "cost" for what, whether increases in user complaints to various parties are "worth it," etc., in a way that is perceived as neutral by all affected parties. Better not to make predictions if the goal is to give a neutral treatment of network functions being impacted today. 3. Acknowledge the controversy. Many of the practices described in this document are controversial, and have been for a long time. There is nothing wrong with that. I agree with Christian that it would be better to state an understanding of that head-on rather than leave it to the reader to decide whether any particular characterization of something described implies an endorsement of it. This has been done before, even in potentially controversial documents that this document references, e.g. RFC 3135. 4. Structure the document in a way that is consistent and logical with minimal repetition. It seems like there are multiple ways that this could be done. Organizing based on use case (per Christian) and then discussing techniques used within each use case is one way; organizing based on technique while mentioning the goals for which each technique is employed is another. At present the document is jumble of these.