IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2018-02-08. These are not an official record of the meeting.
Narrative scribe: John Leslie and Ignas Bagdonas (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
> +---------+----------------------------------------------+ > | Inner | Arriving TRILL 3-bit ECN Codepoint Name | > | Native +---------+------------+------------+----------+ > | Header | Not-ECT | ECT(0) | ECT(1) | CE | > +---------+---------+------------+------------+----------+ > | Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*) | <drop> | > | ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE | > | ECT(1) | ECT(1) | ECT(1)(*) | ECT(1) | CE | > | CE | CE | CE | CE(*) | CE | > +---------+---------+------------+------------+----------+ > > Table 3. Egress ECN Behavior
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
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::
Telechat::
Telechat::
4.1.2 Proposed for Approval
Telechat::
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat::
4.2.2 Proposed for Approval
Telechat::
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
7. Working Group News
7a. Other Business
1123 EST Adjourned
(at 2018-02-08 06:00:04 PST)
draft-ietf-idr-bgp-prefix-sid
Thanks for Acee for addressing my DISCUSS - cleared. Major(ish) issue: Section 5. Advertising BGP Prefix-SID Attribute "The BGP Prefix-SID attribute MAY be attached to labeled BGP prefixes (IPv4/IPv6) [RFC8277] or to IPv6 unicast prefixes [RFC4760]. In order to prevent distribution of the BGP Prefix-SID attribute beyond its intended scope of applicability, attribute filtering SHOULD be deployed." Thank you for including this -- however, as I'm sure you know, the state of BGP filtering in the wild is, er, poor. Can you please provide some additional guidance? For example, could you include an appendix with examples? Or simply a bit more text on determining the scope of applicability? Apologies if I missed this, but should this by default be filtered on eBGP sessions? The included text is a great start, but some more (so people don't miss it and shoot themselves in the foot would be much appreciated. Nits: Section 1: " the SID consists of a label while when SR is applied to the IPv6 dataplane the SID consists of an IPv6 address." I think that "of a label, while" would make this much more readable. It took me a few tries without it. Section 4: " A BGP speaker receiving a BGP Prefix-SID attribute from an EBGP neighbor residing outside the boundaries of the SR domain, MUST discard the attribute unless it is configured to accept the attribute from the EBGP neighbor." Spurious comma between domain and MUST (yeah, I want a comma above, I don't want one here, no pleasing some people. They are nits :-))
I don't see how the MUST in this receiving behavior in Section 4.2. "However, a BGP Prefix-SID attribute corresponding to the BGP IPv6 address family without an IPv6 SID TLV MUST be ignored." makes sense with the MAY in the sending behavior "A BGP speaker that originates an IPv6 prefix with the BGP Prefix-SID attribute MAY include the IPv6 SID TLV." Can you please clarify?
I tend to agree with Mirja that you either don't currently need registry for flags or need it with a stricter policy than First Come First Served. Nits: 4. Receiving BGP Prefix-SID Attribute A BGP speaker receiving a BGP Prefix-SID attribute from an EBGP neighbor residing outside the boundaries of the SR domain MUST discard the attribute unless it is configured to accept the attribute from the EBGP neighbor. A BGP speaker MAY log an error for further analysis when discarding an attribute. Is there any reason why logging is just MAY? This would help big time in debugging issues. You are also using "SHOULD log" in other places in the document. So I suggest: MAY log an error ==> SHOULD log an error (Actually "MAY log" appears twice in the document) I suggest you use a more common "extensibility" instead of "extendibility", but maybe this is just me :-).
(The document has been updated since I made my review notes. Apologies if any of my comments no longer apply.) Substantive: - 1: I agree with Alissa's comment about finding a less controversial example than DPI. -9: last paragraph: Can you offer a citation for the "standard BGP mechansism (filters)"? I assume they are in one of the documents cited in the first paragraph of this section, but it would help to cite the specific document and section. Editorial and nits: - Abstract and section 1: Both are missing an article (probably "The") before "Segment Routing (SR) architecture"
Minor commets: 1) Maybe spell out NLRI on first occurrence (sec 2). 2) Given there are currently no flags defined, wouldn't it be sufficient to use the 8-bit reserved field for flags? Also do you really want to create an empty registry on a first-come first-serve basis for the flags now? Have there been any use cases discussed already? Is it likely that assignments will be made soon and is first-com first-serve the right policy for these expected assignments? Note that such registries can also be created at a later point when really needed.
I support Warren's discuss and Alexey's comment on logging.
BGP Prefix-SID attribute, it MUST program the derived label as the local label for the prefix in its MPLS dataplane. In case of any error, a BGP speaker MUST resort to the error handling rules This seems over-strong, as the next paragraph suggests that you might reject it due to policy. This document defines a new BGP attribute in order to address the use case described in [I-D.ietf-spring-segment-routing-msdc]. It i assumed that the new attribute (BGP Prefix-SID) advertisement is Nit: "is assumed", i think? inherits the security considerations expressed in: [RFC4271] and [RFC3107]. This section seems like it needs to discuss how the security of this mechanism interacts with BGPSEC, etc. Maybe it's just "the same as everything else" but perhaps not...
Please expand "AFI/SAFI" on first use.
Is there a different, less controversial example that could be given in the first paragraph of the document than "pass through deep packet inspection"?
draft-ietf-rtgwg-ni-model
Same remark as in
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lne-model/ballot/#benoit-claise
The title should be: "YANG module for network instance"
This document is NMDA compliant. I should be clearly mentioned. Like in the
RFC7223bis abstract.
No need to repeat the tree-diagram reference in:
The NI model can be represented using the tree format defined in
[I-D.ietf-netmod-yang-tree-diagrams] as:
Like for the LNE YANG module, you still have the -state in the example.
================================================================
Some more feedback from Martin Bjorklund, as YANG doctor:
In 3.1 they have:
The network-instance module is structured to facilitate the
definition of information models for specific types
^^^^^^^^^^^^^^^^^^
This should probably be "data models"
--------------------------------
In 3.1 they show the pre-NMDA split tree:
augment "/ni:network-instances/ni:network-instance/ni:ni-type" {
case l3vpn {
container l3vpn {
...
}
container l3vpn-state {
...
}
}
}
this should be just:
augment "/ni:network-instances/ni:network-instance/ni:ni-type" {
case l3vpn {
container l3vpn {
...
}
}
}
--------------------------------
same in 3.1.2:
+--rw (ni-type)?
| +--:(l3vpn)
| +--rw l3vpn:l3vpn
| | ... // config data
| +--ro l3vpn:l3vpn-state
| | ... // state data
should be
+--rw (ni-type)?
| +--:(l3vpn)
| +--rw l3vpn:l3vpn
| | ...
-------------------
The example in appendix B.2 uses "ietf-routing:routing-state" and
"ietf-interfaces:interfaces-state" but that node is pre-NMDA, and
deprecated in 8022bis and 7022bis. This example should probably be
updated.
All of the examples in §B.1 use IPv4 addresses exclusively. Please update these to use all-IPv6 or a mix of IPv4 and IPv6. See <https://www.iab.org/2016/11/07/iab-statement-on-ipv6/> for details.
Two minor editorial comments: 1) Sec 1.2: I'm surprised to see an open issue listed here. Is there already any plan to address this somehow or is that listed to inform the reader, however, in the second case I would probably rather call it 'limitation' or something like this... 2) Sec 2: "In this document, we consider network devices that support protocols and functions defined within the IETF Routing Area, e.g, routers, firewalls, and hosts. " I assume that this yang module can also be used for routing protocols and functions that have not been defined in the IETF?
draft-ietf-rtgwg-lne-model
Please make sure you review Dan's OpsDir review (https://datatracker.ietf.org/doc/review-ietf-rtgwg-lne-model-05-opsdir-lc-romascanu-2018-01-25/) -- he has some great suggestions to further improve the document I also have a few *very* minor nits: Section 2: Overview "The logical-network-element module augments existing interface management model by adding an" Perhaps "management models" (plural)? Section 3.1. LNE Instantiation and Resource Assignment "When an bind-lne-name is set to a valid LNE name, an implementation " Perhaps "When a ..." ?
This document references/augments rfc7223. It should reference rfc7223bis instead. The examples in Appendix B still show the interfaces-state subtree, but the main text doesn't. Are there any other changes in rfc7223bis that would impact this document?
Russ's Gen-ART review included comments about the "vulnerable parameters" in the security considerations section in version 5. Version 6 does not seem to address those comments, nor do I see any response in email. If the authors do not intend to add the requested information, it would be good to at least say so (and hopefully explain why) via email.
No objection to the document, but a few points must addressed. - I agree with Alvaro's point: the example should be corrected. - This draft is NMDA compliant: it should be mentioned. From Dan Romascanu's OPS DIR, at least the 3 first three points should be addressed (the 4rth one is a nice to have, but a bigger task IMO): This is a very useful, well thought and well written document, which reflects work and discussions within the RTG and OPS areas. From an operational point of view it's a very useful tool in support of network operators that will manage and configure logical elements. I believe that the document is almost ready, but there are a number of issues that are worth being discussed and addressed before approval by the IESG. 1. The name and scope of the document as presented in the title and Abstract are not exactly reflecting the content. LNEs are not YANG LNEs as the title says, and the type of module (a YANG module) being defined is not stated in the Abstract. I would suggest that the document actually defines 'A Data Model and YANG Module for Logical Network Elements'. 2. There is no reference and relationship definition in the document to the YANG Data Model for Hardware Management defined in https://tools.ietf.org/html/draft-ietf-netmod-entity-07. Actually the LNEs are almost similar with the 'logical entities' that were dropped from the netmod-entity work. It is expected that in the future network operators will use both data models and the respective YANG modules when managing hardware devices on which logical network entities are being run. Even if this relationship is not explicitly present in the DM, I believe that it needs to be looked at and mentioned in the document. 3. In Section 2 I see: 'The logical-network-element module augments existing interface management model by adding an identifier which is used on physical interface types to identify an associated LNE.' I am wondering why the mentioning of 'physical interface types' here. What if the interface type in not 'physical' representing a protocol layer or sublayer on the device? After all, if all interfaces to be considered were 'physical' we could have augmented the entity hardware module rather than the interfaces module, as all physical interfaces are represented there as well. 4. Sections 3.2 and 3.3 seem to be written for the benefit and the perspective of the implementations writers rather than of the operators. Are there any hints, advice, or indications for the operators using the module to manage their LNEs? These could be described also in the examples appendices, which are otherwise very useful to illustrate and explain the models.
I agree with the SecDir reviewer's recommendations and would like to see text added to the Security considerations section as suggested: https://datatracker.ietf.org/doc/review-ietf-rtgwg-lne-model-05-secdir-lc-yu-2018-02-06/
All of the examples in Appendix B and its subsections use IPv4 addresses exclusively. Please update these to use all-IPv6 or a mix of IPv4 and IPv6. See <https://www.iab.org/2016/11/07/iab-statement-on-ipv6/> for details.
As several others have noted, the major concerns below from the Gen-ART reviewer need to be addressed: Section 4 listed three data nodes that are sensitive or vulnerable: - /logical-network-elements/logical-network-element - /logical-network-elements/logical-network-element/managed - /if:interfaces/if:interface/bind-lne-name All three of them deserve a bit more discussion, although the middle one is covered in much more detail than the other two. If a bad actor gets "unauthorized access" is there something more specific about each of these that can be said? The characterization of "network malfunctions, delivery of packets to inappropriate destinations, and other problems" seems very broad. Consequences that are specific to these data nodes would be more helpful to the reader.
draft-farrel-sfc-convent
In a comment vying for least useful comment ever: 'Packets are classified at the SFC network ingress boundaries by Classifiers (section 4.4 of [RFC7665]) and have an NSH applied to them." I suspect this should be "and have *a* NSH applied to them". (hey, I did warn you)
This spec enables an SC node to create new packets and therefore must provide congestion control consideration to avoid network overload from these packets, e.g. in the simplest case requiring a maximal sending rate/minimal time interval between to packets. I also requested an additional TSV-ART review for further feedback and recommendations for a potential solution.
I think this document should update RFC8300 as it does not only register an new protocol but also changes some of the process for this specific case.
Thanks for the security considerations, I think these look good for what this document should address adding the possible considerations for metadata only NSH. Integrity protection, authentication and other things lacking in SFC and NSH should be addressed in other documents (and it's sadly not, but this isn't the document for that).
The need to protect the metadata is not modified by this document and forms part of the NSH definition found in [I-D.ietf-sfc-nsh]. Nit: I wouldn't limit this to encryption. If you care about integrity/data origin authentication, then encryption may not supply that,
draft-ietf-trill-address-flush
NoObj in the "I read the protocol action, and I trust the sponsoring AD so have no problem (and have no cycles)" sense.
I have some non-blocking comments/questions: (1) Why are the 2 VLAN Block encodings needed? More important, when should each be used? Section 2.2 says that "All RBridges implementing the Address Flush RBridge Channel message MUST implement types 1 and 2, the VLAN types...", but I didn't see anything about the VLAN Block Only Case (2.1). I'm wondering if there will be cases where the support won't match and the message will then be ineffective. (2) In the 2.2.* sections, the description of some of the TLVs says (when the Length is incorrect) that "...the Address Flush message MUST be discarded if the receiving RBridge implements Type x". What if that type is not supported -- I would assume you still want to discard? BTW, the Type 5 description doesn't qualify dropping based on the type support. (2a) Other descriptions (type 1,2,6) just talk about ignoring (not discarding). Is there an intended difference in the behavior? (3) Section 2 says that "Address Flush protocol messages are usually sent as multi-destination packets...Such messages SHOULD be sent at priority 6". It is not clear to me whether unicast packets (mentioned later) should also have the same priority.
I appreciate the detail in the shepherd's writeup concerning the initial IPR disclosure. However, another (third party) disclosure was entered yesterday. I will leave this to Alia to decide, but I wonder if the WG shouldn't have some time to consider that disclosure prior to the IESG, and perhaps to give the first party for that disclosure a chance to disclose terms.
This is probably a dumb question but I notice that there's no filtering here for for example, VLAN IDs which the sending agent doesn't seem to be relevant for. Can you explain why that's not needed/desirable?
Thanks to everyone who contributed to writing this document.
I'm concerned that the interaction between the various extensible Address Flush
message TLVs isn't very clearly spelled out. As far as I can tell, the text that
attempts to describe the interactions is:
> If the set of MAC addresses accumulated from parsing the address
> flush message is null, the message applies to all MAC addresses.
> If the flag indicating the presence of an All Data Labels TLV is
> true, then the address flush message applies to all Data Labels and
> the set of Data Labels and block of Data labels specified has no
> effect. If the flag indicating the presence of an All Data Labels TLV
> is false, then the address flush messages applies only to the set of
> Data Labels accumulated from parsing the message; if that set is
> null, the address flush message does nothing.
Based on this (and the fact that their implementation is optional), I infer
that the MAC address TLVs are intended to further restrict the addresses
indicated by TLV types 1 through 5, rather than expand upon them. I'm less
sure about whether they have any impact on Type 6. I would expect that they
do, but the text above ("applies to all Data Labels") kind of sounds like they
don't.
What would seem to make sense here (inasmuch as it provides maximal flexibility)
is:
if (TLV7 ∪ TLV8 = {})
Addresses to Flush = (TLV1 ∪ TLV2 ∪ TLV3 ∪ TLV4 ∪ TLV5 ∪ TLV6)
else
Addresses to Flush = (TLV1 ∪ TLV2 ∪ TLV3 ∪ TLV4 ∪ TLV5 ∪ TLV6) ∩ (TLV7 ∪ TLV8)
If that's the intention, I think the normative explanation needs to be clearer.
If that's not the intention, I sill think the normative explanation needs to be
clearer.
My remaining comments are editorial.
---------------------------------------------------------------------------
Please expand the following acronyms upon first use and in the title;
see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.
- TRILL
- TC
- TCN
- MSTP
While the following terms are defined in cited documents, you may wish to also
consider expanding them in this document's acronym list for the convenience of
the reader:
- MAC
- FCS
Finally, please explain the use of "RB1" in the Introduction.
---------------------------------------------------------------------------
§1:
> Another example is based on Appendix A.3 of [RFC6325] ("Wiring Closet
> Topology") presents a bridged LAN connected to a TRILL network via
> multiple RBridge ports.
This should be either:
Another example, based on Appendix A.3 of [RFC6325] ("Wiring Closet
Topology"), presents a bridged LAN connected to a TRILL network via
multiple RBridge ports.
or...
Another example is based on Appendix A.3 of [RFC6325] ("Wiring Closet
Topology"), which presents a bridged LAN connected to a TRILL network
via multiple RBridge ports.
---------------------------------------------------------------------------
§1.1:
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in [RFC2119].
This document makes use of lowercase versions of these terms as well; please
consider using the RFC 8174 boilerplate.
---------------------------------------------------------------------------
§2.2:
> VLANs/FGLs if it occurs in any TLV in the address flush message. A
> MAC addresses might be indicated more than once due to overlapping
"A MAC address..." or "MAC addresses..."
---------------------------------------------------------------------------
§2.2:
> MAC addresses if it occurs in any TLV in the address flush message.
> If the set of MAC addresses accumulated from parsing the address
> flush message is null, the message applies to all MAC addresses.
> If the flag indicating the presence of an All Data Labels TLV is
> true, then the address flush message applies to all Data Labels and
The staggered indenting here looks a bit odd. Were these intended to be a
bulleted list?
draft-ietf-trill-ecn-support
I agree with Mirja about the status of L4S, but would go even farther - L4S is only one of the ECN experiments that https://datatracker.ietf.org/doc/rfc8311/ was intended to accommodate, so you might want to capture that in the appendix (basically saying "L4S is one example of the ways TRILL ECN handling may evolve", or something like that). Is If an RBridge supports ECN, for the two cases of an IP and a non-IPR inner packet, the egress behavior is as follows: really "non-IPR"? I'm guessing it should be "non-IP". s/significnat/significant/
Given L4S is not published yet and in any case experimental, I would recommend to remove section 4.2 entirely and just keep the appendix as an informational documentation of the proposed alogrithm.
Just a typo in section 6: s/ significnat / significant (And I see Spencer already caught it :-) )
Thanks to the authors, chairs, shepherd, and working group for the effort that
has been put into this document.
I have concerns about some ambiguity and/or self-contradiction in this
specification, but I suspect these should be easy to fix. In particular, the
behavior defined in Table 3 doesn't seem to be consistent with the behavior
described in the prose.
For easy reference, I've copied Table 3 here:
> +---------+----------------------------------------------+
> | Inner | Arriving TRILL 3-bit ECN Codepoint Name |
> | Native +---------+------------+------------+----------+
> | Header | Not-ECT | ECT(0) | ECT(1) | CE |
> +---------+---------+------------+------------+----------+
> | Not-ECT | Not-ECT | Not-ECT(*) | Not-ECT(*) | <drop> |
> | ECT(0) | ECT(0) | ECT(0) | ECT(1) | CE |
> | ECT(1) | ECT(1) | ECT(1)(*) | ECT(1) | CE |
> | CE | CE | CE | CE(*) | CE |
> +---------+---------+------------+------------+----------+
>
> Table 3. Egress ECN Behavior
>
> An asterisk in the above table indicates a currently unused
> combination that SHOULD be logged. In contrast to [RFC6040], in TRILL
> the drop condition is the result of a valid combination of events and
> need not be logged.
The prose in this document indicates:
1. Ingress gateway either copies the native header value to the TRILL ECN
codepoint (resulting in any of the four values above) or doesn't insert
any ECN information in the TRILL header.
2. Intermediate gateways can set the CCE flag, resulting in "CE" in the
table above.
Based on the above, a packet arriving at an egress gateway can only be in one of
the following states:
A. TRILL header is Not-ECT because no TRILL node inserted ECN information.
B. TRILL header value == Native header value because the ingress gateway
copied it from native to TRILL.
C. TRILL header is "CE" because an intermediate node indicated congestion.
If that's correct, I would think that any state other than those three needs
to be marked with an (*). In particular, these two states fall into that
classification, and seem to require an asterisk:
- Native==CE && TRILL==ECT(0)
- Native==ECT(0) && TRILL==ECT(1)
In addition, the behavior this table defines for Native==ECT(0) && TRILL==ECT(1)
is somewhat perplexing: for this case, the value in the TRILL header takes
precedence; however, when Native==ECT(1) && TRILL==ECT(0) the Native header
takes precedence. Or, put another way, this table defines ECT(1) to always
override ECT(0). I don't find any prose in here to indicate why this needs to be
treated differentially, so I'm left to conclude that this is a typographical
error. If that's not the case, please add motivating text to Table 3 explaining
why ECT(1) is treated differently than ECT(0) for baseline ECN behavior.
I also have a small handful of editorial suggestions and nits to propose. Please expand "TRILL" upon first use and in the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. --------------------------------------------------------------------------- §1: > In [RFC3168] it was recognized that tunnels and lower layer protocols "In [RFC3168], it was..." (insert comma) --------------------------------------------------------------------------- §2: > These fields are show in Figure 2 as "ECN" and "CCE". The TRILL-ECN "...are shown..." > The CRItE bit is the critical Ingress-to-Egress summary > bit and will be one if and only if any of the bits in the CItE range > (21-26) is one or there is a critical feature invoked in some further "...if any of the bits... are one or..." (replace "is" with "are") > The first three have the same meaning as the corresponding ECN field > codepoints in the IPv4 or IPv6 header as defined in [RFC3168]. Section 1.1 defines "IP" to mean both IPv4 and IPv6. It would seem cleaner and easier to read if the document were to leverage that definition here. > However codepoint 0b11 is called Non-Critical Congestion Experienced "However, codepoint..." (insert comma) --------------------------------------------------------------------------- §3.3.2: > If an RBridge supports ECN, for the two cases of an IP and a non-IPR "...non-IP" --------------------------------------------------------------------------- §4: > Section 3 specifies interworking between TRILL and the original > standardized form of ECN in IP [RFC3168]. Please indicate this at the top of Section 3. When I was puzzling over Table 3, I spent some time trying to figure out whether the behavior I describe in my DISCUSS above was due to behavior described in RFC 8311 or the experiments it contemplates. --------------------------------------------------------------------------- Appendix A: > o the meaning of CE markings applied by an L4S queue is not the same > as the meaning of a drop by a "Classic" queue (contrary to the > original requirement for ECN [RFC3168]). I think, when citing this exception, it makes much more sense to point to RFC 8311 (where the exception to RFC 3168's requirement is defined) than to RFC 3168 in a vacuum. > Instead the likelihood Insert a comma after "Instead". > that the Classic queue drops packets is defined as the square of > the likelihood that the L4S queue marks packets (e.g. when there Insert a comma after "e.g.,"
draft-ietf-netmod-yang-tree-diagrams
This is really accessible for those of us who don't speak YANG fluently, but have working groups that are starting on YANG models. Thanks for doing it.
Duh.
Nice move!!
draft-ietf-tls-dnssec-chain-extension
I was one of the very early DANE people / WG chair / etc. Y'all have come along, commandeered our protocol..... and made it much better (and deployable)... <insert old man shakes fist at cloud meme>. Seriously, thank you -- I was saving this document to be able to do a very thorough review, but unfortunately have run out of time, so only have one comment to offer: Section 3.1. Protocol, TLS 1.2 "Therefore, a server MUST NOT construct chains for domain names other than its own." -- what is a servers' "domain name"? E.g: My webserver has certs with many SANs, and SNI, etc Perhaps this should be more along the lines of "MUST NOT construct chains for domain names which it is not responsible? (Obviously, this will also require some wordsmithing, I don't really know what it means to be "responsible" for a domain; perhaps "domains it doesn't have certificates for"? something...)
I am happy to see this published, but have a few minor comments: - I agree with Alexey's comments. -3.4: "If the TLSA record set was synthesized by a DNS wildcard, the chain must include the signed NSEC or NSEC3 records that prove that there was no explicit match of the TLSA record name and no closer wildcard match." Should that "must" be a "MUST"? - Nit in Authors List: Unless I've missed something, Richard's affiliation is no longer current. (I only point it out in case it's an oversight; I have no objection if it's that way on purpose.)
I think this is a useful document and I will ballot Yes once my small issues are resolved: 1) In 3.4: The first RRset in the chain MUST contain the TLSA record set being presented. However, if the owner name of the TLSA record set is an alias (CNAME or DNAME), then it MUST be preceded by the chain of alias records needed to resolve it. DNAME chains should omit SHOULD? What are the implications if this is not followed? unsigned CNAME records that may have been synthesized in the response from a DNS resolver. 2) TLS 1.3 needs to be a normative reference, but it is not even listed in References.
The first mention of NSEC3 need a normative reference.
No objection, Alexey's DISCUSS already has hit the issue I also noted.
This draft seems generally sound, but I believe there are pieces that are still underspecified. These should be easy to fix. the Signer's Name field in canonical form and the signature field excluded. IMPORTANT: I'm not sure that this is actually sufficient to allow an independent implementation without referring to the other documents. I mean, I think I pretty clearly can't validate this chain from the above. Similarly, although I think this is enough to break apart the RRSETs into RRs, it doesn't tell me how to separate the RRSETs from each other. I think you need to either make this a lot more complete or alternately stop saying it's sufficient. abort the connection, the server uses the domain name associated with the server IP address to which the connection has been established. IMPORTANT: "the domain name" is not unambiguous. Hosts can have multiple names for the same IP. DNSSEC authentication chain extension from a server, SHOULD use this information to perform DANE authentication of the server. In order to do this, it uses the mechanism specified by the DNSSEC protocol IMPORTANT: What happens if the DANE validates but the cert is revoked or alternately the cert validates but DANE does not? [RFC4035] [RFC5155]. This mechanism is sometimes implemented in a DNSSEC validation engine or library. IMPORTANT: shouldn't it be a requirement to perform this validation?
typically not be used for general DNSSEC validation of TLS endpoint
names.
Can you rephrase this. I *think* it means "it's not used to validate the A/AAAA
lookup"...?
validation of endpoint names, but is more appropriate for validation
of DANE TLSA records.
Same comment as abive
This mechanism is useful for TLS applications that need to address
the problems described above, typically web browsers or VoIP and XMPP
applications. It may not be relevant for many other applications.
Nit; cites to SIP/XMPP appropriate here,
ClientHello message that the DNS authentication chain be returned in
the (extended) ServerHello message. If the server is configured for
DANE authentication, then it performs the appropriate DNS queries,
This is not correct for TLS 1.3.
3.1. Protocol, TLS 1.2
You should probably provide some guidance about whether the server should still
provide the whole X.509 chain to the client. I believe with these semantics,
the server cannot tell which DANE mode the client wants and therefore has to
provide the entire chain.
Servers receiving a "dnssec_chain" extension in the ClientHello, and
which are capable of being authenticated via DANE, MAY return a
serialized authentication chain in the extended ServerHello message,
Nit: I believe you want to remove the commas here, as they indicate a
nonrestrictive clause.
arbitrary domain names using this mechanism. Therefore, a server
MUST NOT construct chains for domain names other than its own.
"its own" is a bit fraught, as servers may not actually know all their domain
names, at least at the TLS layer.. Can you be more specific about what the
server algorithm is.
Servers receiving a "dnssec_chain" extension in the ClientHello, and
which are capable of being authenticated via DANE, SHOULD return a
serialized authentication chain in the extension block of the
Why is this a SHOULD where the corresponding reqt for TLS 1.2 and below is a
MAY?
to a DNSSEC trust root. This has the added benefit of mitigating an
unknown key share attack, as described in [I-D.barnes-dane-uks],
since it effectively augments the raw public key with the server's
"unknown key share (UKS)"
handshake, to a domain name which has been validated as belonging to
the owner name.
The key point here is that the commitment is bound to the EE key. Also, this
only really works for TLS 1.3 and modes with EMS because otherwise there are
other UKS attacks
I think you probably want to cite SIGMA and triple handhshake here.
opaque AuthenticationChain<0..2^16-1>
Is 0 actually appropriate here as a lower bound? Presumably at least one such
instance must be present?
RR(i) = owner | type | class | TTL | RDATA length | RDATA
I assume the notation here is "i is the ith RR"?
Is there a reason not to describe this in TLS language?
. DNSKEY
RRSIG(. DNSKEY)
How does this differ from the algorithm that you would use in response to the
TLSA query?
the draft is adopted by the WG, the authors expect to make an early
allocation request as specified in [RFC7120].
Do you want this to be marked RECOMMENDED?
I like this mechanism and look forward to its deployment. I have one point of clarification and a small handful of editorial comments. First, the point of clarification: §4: > if the server does not recognize the > provided name and wishes to proceed with the handshake rather than to > abort the connection, the server uses the domain name associated with > the server IP address to which the connection has been established. Unless I missed something important, this scenario doesn't seem to make much sense: if the client provides name A and the server replies with name B, the client either (1) isn't performing server name validation (in which case it is nonsense for the client to ask for a dnssec_chain), or (2) is going to error out the connection. Do I have that right? If there's some situation in which the server acting as described above provides some benefit, I would love to see it described in here. If it's just a matter of having completely described behavior for corner cases, it may be worthwhile indicating that the client will reject the connection if the server decides to complete the handshake like this. --------------------------------------------------------------------------- > Intended status: Standards Track R. Barnes > Expires: July 27, 2018 Mozilla s/Mozilla/Cisco/ --------------------------------------------------------------------------- §1: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. This document has significant usage of these terms in lowercase. Please consider using the boilerplate from RFC 8174 instead. --------------------------------------------------------------------------- §3.3: > the case in DANE in which a client either ignores the name in > certificate (as specified in [RFC7671] or there is no attestation of Nit: "...in the certificate..." Nit: Add closing paren after [RFC7671] --------------------------------------------------------------------------- §4: > specific processing needed for aliases and wildcards. If DNS > responses messages contain any domain names utilizing name Nit: "response"
Two minor, mostly editorial comments: 1) Intro (sec 2): " It also provides the ability to avoid potential problems with TLS clients being unable to look up DANE records because of an interfering or broken middlebox on the path between the client and a DNS server." Is that actually a well-known problem (can you provide a reference?) or would it be enough to say something like this: " It also provides the ability to avoid potential problems with TLS clients being unable to look up DANE records when DNS server is not reachable." 2) IANA Considerations should probably be updated.
draft-ietf-bier-mvpn
[I am balloting No Objection, and not DISCUSS [1], because I think this comment is very easy to address.] The reference to draft-ietf-bess-mvpn-expl-track (EXPLICIT_TRACKING) should be Normative because of the use of the LIR-pF flag in this document. [1] https://www.ietf.org/iesg/statement/discuss-criteria.html#stand-disc
-1, last paragraph: There are a few instances of lower case versions of 2119 keywords. Please consider using the boilerplate from RFC 8174.
One of the most readable documents on MVPN that I can remember reading. Thanks for that. When reading Section 2.2, I found myself wondering why you'd choose the optional explicit tracking mechanism, but found this text This method greatly reduces the number of S-PMSI A-D routes that a BFIR needs to originate; it can now originate as few as one such route (a (C-*,C-*) S-PMSI A-D route), rather than one for each C-flow. However, the method does not provide a way for the BFIR to assign a distinct label to each C-flow. Therefore it cannot be used when segmented P-tunnels are in use (see Section 4 for an explanation). in Section 2.2.2. I wonder if it's worth moving that text to the end of Section 2.2, so the reader goes into 2.2.1 and 2.2.2 understanding the advantage of the optional mechanism?
draft-mm-wg-effect-encrypt
No Objection, however I fully support the words in Alissa's DISCUSS and they should be given extensive consideration
Thanks for handling my other comments, the abstract and intro for setting context are much improved. I found some sections still though need some neutrality/tweaking, others have already provided detailed comments. For me, section 8 as the "way forward" is especially weak and confusing. As the last section of a very detailed, lengthy document, a more concise, stronger summary is needed on the purpose of the document. "Changes to improve encryption or to deploy OS methods have little impact on the detection of malicious actors; they already have access to strong encryption." And the last two sentences cast a foreboding outlook: "..but make passive monitoring broadly cost prohibitive. This is meant to restrict monitoring to sessions where there is reason to have suspicion." The End for this 40-page story?
Really thanks a lot for all the work on this document! I changed my position from discuss to no objection with these edits now because I think there are still things that could be improved to make the document more useful. However, I also think that it is important to publish this document soonish and I don't think any additional delay would help the message significantly. ------------------------------- Old comment for the record: ------------------------------- 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.
* 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. This version is much improved. When you talk about logging, maybe mentioning "protocol trace logging" or "PDU logging" as a useful tool for troubleshooting that can be provided by both client and server endpoints? DMARC (RFC 7489) should probably be mentioned in Section 5.1 where you mention ARF.
This is a considerably better document than the previous versions I have reviewed. Thanks for all that work. But of course, I still have some comments :-) Substantive Comments: -2.2.2, 2nd paragraph: "... for example, many forms of communications (from isochronous/real-time to bulk/elastic file transfer) will take place over HTTP port 80 or port 443, so only the messages and higher-layer data will make application differentiation possible." I'm confused about the use of port 443 in that sentence; presumably traffic to 443 will be encrypted and not allow differentiation using higher-layer data. -2.2.4: This section lacks a discussion of the impact of encryption. -2.2.5, last paragraph: I understand that techniques that require endpoint cooperation might be out of scope, but the tone of this paragraph makes it sound like requiring endpoint cooperation is a negative. Is that the intent? -2.3, section title: The title is only partially evocative of the section content. I suggest adding "content filtering". -2.3.1: I think it might be worth mentioning that an "intercepting certificate" requires endpoints to be configured to trust that certificate. (I assume we are not talking about the more unsavory practice of certificates that misrepresent their subjects. -2.3.4 I concur with Adam that this section should explicitly mention "cross-site user tracking" as one of the common motivations for header insertion/enrichment. I think it should also include a mention of RFC 8165. -5.2: This section doesn't seem to include discussion of the impact of encryption. Editorial and nits: -IDNits finds a number of unused references, and a few other reference issues. Please check. - Abstract: 2nd sentence is hard to parse, and ends with a comma splice. - 1, 2nd paragraph: " The following informational documents consider the end to end (e2e) architectural principle, a guiding principle for the development of Internet protocols [RFC2775] [RFC3724] [RFC7754]." Is the comma correct? It currently reads along the lines of "The documents consider the e2e principle, and we think that it is a guiding principle...", but I think you might mean "The documents consider the e2e to be a guiding principle..." -1, 3rd paragraph: "... (including methods for network endpoints where applicable)..." Should that say "methods that rely on network endpoints"? -2.1.1: Please expand "CAIDA" -2.1.1: Paragraph starting with " When using increased encryption, operators lose a source of data that may be used to debug user issues." I don't think the operators are the ones using the encreased encryption in that sentence. Perhaps "When endpoints use increased encryption..." or even (When increased encryption is used..." -2.1.3, 2nd paragraph: "The ability to examine layers and payloads above transport provides a new range of filtering opportunities at each layer in the clear. " Should "new range" be "increased range"? -2.1.3, third paragraph: The last sentence seems out of place. Is the point of the paragraph to point out that the use of these monitoring techniques for DoS mitigation can't be distinguished from the use of them for privacy violation? -2.2.1: Please expand "QUIC" and add a citation. -2.2.3, last sentence: Sentence fragment. -2.2.4, first sentence: Comma splice. -2.2.5, first paragraph: " Encryption of packet contents at a given protocol layer usually makes DPI processing of that layer and higher layers impossible. " This sentence seems misplaced; the section is not about DPI. -- same paragraph: I don't understand the point(s) of the last two sentences. -2.2.5, third paragraph: "The Enhanced Multimedia Broadcast/ Multicast Services (3GPP eMBMS) - trusted edge proxies facilitate delivering same stream to different users, using either unicast or multicast depending on channel conditions to the user. " I can't parse that sentence. -2.3.3: Please make the "SHOULD" lower case. Since this document does not use RFC 2119/8174 keywords, a capitalized SHOULD should not appear outside of a literal quote. -3: "Businesses understanding the threats of monitoring in hosted environments only increased that pressure to provide more secure access and session encryption" Why "only"? That seems to suggest one would expect some different result. -3.1.2: This section is about Hosting SPs, but the last two paragraphs seem to be about ASPs. While I realize those may sometimes be the same organization, they are architecturally distinct. -3.2.2: "STARTTLS ought have zero effect..." "Ought to have zero effect" or "has little effect"? (If the former, it's safe to say "should" since this draft does not use RFC 2119 keywords.) -3.2.2, last paragraph: Should "SPAM filtering" be "content-based SPAM filtering"? -4.2: What does it mean for tools to "use" keywords? Does this mean "search for" or "monitor for" keywords? -5.4: This seems to say that "Detection and Mitigations" involves thousands of hosts, etc. I think the point is that the botnets themselves may involve thousands of hosts..." -7 and subsections: It looks like the editing of this section is not finished; several sections indicate they are to be deleted. -7.4: Please describe what you mean by "transit proxies". I can't parse item 4. The entire section could use proofreading for missing articles. -12: Are there really no normative references? The definition of a "normative reference" is any reference needed to fully implement or _understand_ the document. This is true for both informational and standards-track documents. Do you think a reader can fully understand this document if they ignore every reference? (I'm willing to accept that the answer might be "yes" given the nature of this draft--but that situation is rare in practice.)
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...
Thank you for this important OPS/SEC document, which has improved lately. 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)Thanks for this improved doc. For me, the key document aspects are: The goal is to help inform future protocol development to ensure that operational impact is part of the conversation. Perhaps, new methods could be developed to accomplish some of the goals of current practices despite changes in the extent to which cleartext will be available to network operators (including methods for network endpoints where applicable). ... This document lists a collection of functions currently employed by network operators that may be impacted by the shift to increased use of encryption. This draft does not attempt to specify responses or solutions to these impacts, but rather documents the current state.
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/
Thank you for the improved document.
I have completely re-reviewed the latest version. First, I want to
thank you for toning down some of the material that I was concerned
about.
Unfortunately, the fundamental concern that motivated my DISCUSS
remains: I do not believe that this document matches the consensus
of the IETF community.
Specifically, this document takes at face value a large number of
claims about the necessity/value of certain practices that either are
controversial within the IETF or that there is, I believe, rough
consensus to be actively bad, and that in many cases, encryption is
specifically designed to prevent. I have noted a number of these
below, but I do not believe that this is an exhaustive list (going
through my previous DISCUSS, I see that I noted a number of these but
that still appear to be unaddressed.)
DISCUSS
session encryption that deployed more easily instead of no
encryption.
I think I understand what you are saying here, but the term
"breakable" seems very unfortunate, especially in the context of this
document. The only such shift I am aware of that has received
acceptance in IETF is one from always requiring fully authenticated
encryption to allowing unauthenticated encryption, which you document
in the next paragraph. I recognize that there are other perspectives
(e.g., those in draft-rhrd) but those are pretty far from IETF
consenus. Accordingly, I think you should remove this sentence.
motivation outside of privacy and pervasive monitoring that are
driving end-to-end encryption for these content providers.
This section seems kind of confusing, at least as applied to
HTTP. There are three kinds of cache in HTTP:
- Reverse proxy caches (the kind CDNs run)
- Explicit forward proxy caches
- "Transparent" intercepting caches
The first of these move to HTTPS just fine and that's typically how
CDNs do it. Explicit forward proxy caches are largely going away, but
part of the point of this kind of end-to-end encryption is to hide
data from those caches. Transparent intercepting caches that the user
didn't opt into are a bad thing, so having them go away is a positive.
document existing practices, the development of IETF protocols
follows the guiding principles of [RFC1984] and [RFC2804].
This is pretty opaque in this context. It should explicitly state that
the IETF's position is that we do not engineer for these use cases,
not just to cite the RFCs.
based billing, or for other reasons, possibly considered
inappropriate by some. See RFC7754 [RFC7754] for a survey of
Internet filtering techniques and motivations. This section is
I don't think this accurately represents the RFC, which makes clear
that the IAB consensus is that filtering is bad:
" From a technical perspective, there are no perfect or even good
solutions -- there is only least bad. On that front, we posit that a
hybrid approach that combines endpoint-based filtering with network
filtering may prove least damaging. An endpoint may choose to
participate in a filtering regime in exchange for the network
providing broader unfiltered access."
detect or prevent attacks as well as to guarantee service level
expectations. In some cases, alternate options are available when
encryption is in use, but techniques like that of data leakage
These certainly are use cases, but you really need to acknowledge that
it's also a form of user surveillance.
Some DLP tools intercept traffic at the Internet gateway or proxy
services with the ability to man-in-the-middle (MiTM) encrypted
session traffic (HTTP/TLS). These tools may use key words important
to the enterprise including business sensitive information such as
trade secrets, financial data, personally identifiable information
(PII), or personal health information (PHI). Various techniques are
used to intercept HTTP/TLS sessions for DLP and other purposes, and
are described in "Summarizing Known Attacks on TLS and DTLS"
[RFC7457].
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.
S 5.4.
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.
The transport header encryption prevents trusted transit proxies. It
may be that the benefits of such proxies could be achieved by end to
You don't define a "trusted transit proxy" so I don't know what this
means, and whether they provide any benefit, but this certainly sounds
euphemistic. Generally, "trusted" is not an adjective we associate
with network proxies operated by third parties.
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. As stated in [RFC7258], "an appropriate balance
(between network management and PM mitigations) will emerge over time
as real instances of this tension are considered."
Much of the context of this debate is about whether operators not
being able to do the things in this document is a problem, and this
seems to presume the answer.
This optimization at network edges measurably improves real-time
transmission over long delay Internet paths or networks with large
Do you have a citation for this claim?
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 as the typical
corporate user does not access sites that are not well-known to these
tools, but may be noticeable to those in research who are unable to
access colleague's individual sites or new web sites that have not
yet been screened. In situations where new sites are required for
access, they can typically be added after notification by the user or
proxy log alerts and review. Home mail account access may be blocked
in corporate settings to prevent another vector for malware to enter
as well as for intellectual property to leak out of the network.
This method remains functional with increased use of encryption and
may be more effective at preventing malware from entering the
network. Web proxy solutions monitor and potentially restrict access
based on the destination URL or the DNS name. A complete URL may be
used in cases where access restrictions vary for content on a
particular site or for the sites hosted on a particular server.
If you are filtering on URL and there is HTTPS involved, then you are
a MITM, and this is potentially noticeable to end-users. We encounter
this regularly when MITM proxies make mistakes in getting into our
trust anchor store.
Re: 0-rating.
user. This feature is impacted if encryption hides the details of
the content domain from the network.
Well, maybe. Facebook's zero rating, for instance, is IP-based.
https://info.internet.org/en/blog/2015/09/24/enhancing-security-and-privacy-of-free-basics/
S 2.2.2.
The presentation here seems biased given that it does not acknowledge
that one of the 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.
Pervasive Monitoring (PM) attacks on the privacy of Internet users is of serious concern to both the user and the operator communities. are of serious concern Traditional network management, planning, security operations, and performance optimization have been developed in an Internet where a large majority of data traffic flows without encryption. While you have a plural/singular mismatch here. Authentication with IPsec [RFC7619] and there are a number of infrastructure use cases such as server to server encryption, where this mode is deployed. While OS is helpful in reducing pervassive Nit, no comma before "where" recommendations from these documents were were built upon for TLS 1.3 to provide a more inherently secure end-to-end protocol. "were were" to-user content encryption schemes, such as S/MIME and PGP for email and encryption (e.g. Off-the-Record (OTR)) for XMPP are used by those interested to protect their data as it crosses intermediary Not, "e.g.," been impacted by increases in encrypted traffic. Only methods keeping with the goal of balancing network management and PM mitigation in [RFC7258] should be considered in solution work resulting from this document. I don't understand what the normative content of this was. upgrades before user experience declines. For example, findings of loss and jitter in VoIP traffic can be a predictor of future customer dissatisfaction (supported by metadata from the RTP/RTCP protocol ) [RFC3550], or increases in DNS response time can generally make interactive web browsing appear sluggish. But to detect such problems, the application or service stream must first be distinguished from others. This is a little hard to read, but generally this information is not encrypted for SRTP/SRTCP. When using increased encryption, operators lose a source of data that may be used to debug user issues. Because of this, application server operators using increased encryption might be called upon more frequently to assist with debugging and troubleshooting, and thus may want to consider what tools can be put in the hands of their clients or network operators. This is phrased as hypothetical, but is there any actual data to support this? We have a lot of experience now with encrypted voice and video as well as Web. Do those providers report any increased level of requests. the new flow and would not be able to route it back to the original POP. I'm having a little trouble understanding this paragraph. Why is this about mobile operators? It seems like it's an issue for anyone who has a service that might have mobile clients. effective at providing data offload when there is a network element close to the receiver that has access to see all the content. This section is also confusing in that it fails to distinguish between proxies of this type that the user opts into from transparent proxies that just do this service without the user's consent. Part of the purpose of encryption is to preclude that. created from the intercepting device to the client's destination, this is an opt-in strategy for the client. Changes to TLSv1.3 do not impact this more invasive method of interception, where this has the I don't understand the cite to TLS 1.3 here. None of this is presently affected by 1.3. endpoints as a service reduces providers' ability to offer parental control. This section makes it seem like there are no other methods that allow for parental control, but that's not true. There are parental control mechanisms which rely on MITM proxies or application interfacing. HTTP headers and content are encrypted, this prevents mobile carriers from intercepting the traffic and performing an HTTP redirect. As a result, some mobile carriers block customer's encrypted requests, Yes, stopping traffic redirection is actually one of the major design purposes of HTTPS. to the customer and additional overhead to the mobile network service provider. This section is basically a commercial for this practice. It needs to acknowledge that it's actually much closer to IETF consensus that it's a bad practice. headers to accomplish the, sometimes considered controversial, functions above. Again, this is precisely the form of attack that HTTPS is intended to prevent. perform SSL/TLS decryption are impacted by the increased use of encryption that prevents interception. I don't really understand what this text means. What is "use of encryption that prevents interception" in the context of tools which already do decryption? [DarkMail]. Of course, SPAM filtering will not be possible on encrypted content. This is not strictly correct, as you can still header filter, etc. over the Internet. Options for monitoring will vary with each encryption approach described below. In most cases, solution have been identified to provide encryption while ensuring management Nit: "solutions have" allow for multiple end user sessions to share the same TCP connection. This rasises several points of interest with an increased use of encryption. TCP session multiplexing should still Typos: rasises be possible when TLS or TCPcrypt is in use since the TCP header information is exposed leaving the 5-tuple accessible. The use TCP session multiplexing of an IP layer encyption, e.g. IPsec, that only I'm not sure if this is correct. What precisely do you mean by "TCP session multiplexing"? A cite would be helpful here. center. HTTP pipelining requires both the client and server to participate; visibilty of packets once encrypted will hide the use of HTTP pipelining for any monitoring that takes place outside of the Typo: visibility traffic cannot be intercepted, encouraging alternate options such as performing these functions at the edge. I'm not seeing the relevance of this. Who is proposing solutions in which encrypted traffic cannot be intercepted at the outgoing network edge. owing to concealment of critical headers and payloads. Many forms of enterprise performance management may be similarly affected. Again, this is sort of transparent caching is an anti-pattern, so this document ought to acknowledge that, parts of the address assignment/management protocols, critical for SAVI mechanisms, can result in a dysfunction of the SAVI mechanisms. Does anyone actually deploy SAVI? If not, encryption isn't having much of an impact. network filters look out for seeing a Server Name Indication extension, they may not find one. The SNI Encryption in TLS Through Tunneling [I-D.ietf-tls-sni-encryption] draft has been adopted by the This doesn't really follow. I mean they "may not" but overwhelmingly they will
Thanks for all the work that has gone into this document. The framing and tone
is much improved over -10, and the reorganization of section 7 into the rest
of the document helps a lot. I do have a handful of comments. In particular,
I think the omission in section 2.3.4 is very important; however, I
wanted to clear my discuss and trust the sponsoring AD to do the right thing
here rather than re-issuing a different discuss position.
---------------------------------------------------------------------------
§2.1.2 -- I am surprised that there is so much discussion of fields that are
not generally encrypted in practice (e.g., RTP headers, TCP headers). It may
be worth distinguishing between session-layer, transport-layer and
network-layer security.
(I think I mentioned this in my initial review, and saw neither a response nor a
document change in reaction to it.)
---------------------------------------------------------------------------
§2.2.3 -- This section reads like a set of unfinished "notes to self" for the
authors' later use. Minimally, I would suggest restructuring the sentence
fragments in this section into sentences. I will also note that section 2
indicates that the following sections will discuss both (a) purpose of the
technique, and (b) fields used to achieve this purpose. This section appears
to lack the latter.
---------------------------------------------------------------------------
§2.2.5:
> For example, network caching of popular content at a
> location close to the requesting user can improve delivery efficiency
> (both in terms of lower request response times and reduced use of
> International Internet links when content is remotely located), and
> authorized parties acting on their behalf use DPI in combination with
> content distribution networks to determine if they can intervene
> effectively. Caching was first supported in [RFC1945] and continued
> in the recent update of "Hypertext Transfer Protocol (HTTP/1.1):
> Caching" in [RFC7234].
The transition from the general case of caching to the specific case of HTTP
proxy caching (and the subsequent change back to the general case) seems
rather abrupt. Consider splitting the HTTP proxy caching out into a separate
paragraph.
---------------------------------------------------------------------------
§2.2.5:
> The Enhanced Multimedia Broadcast/
> Multicast Services (3GPP eMBMS) - trusted edge proxies facilitate
> delivering same stream to different users, using either unicast or
> multicast depending on channel conditions to the user.
This passage also reads like outline notes rather than a finished document.
---------------------------------------------------------------------------
§2.2.5:
> preserving end-to-end security: AMT, for instance, allows CDNs to
Please expand "AMT".
---------------------------------------------------------------------------
§2.2.7:
> A goal is protecting end-user
> data -- but at the same time not making the network inoperable or
> unmanageable.
I fear this sentence falls back to the hyperbolic tone that plagued version
-10 of this document. I suggest something more along the lines of "...not
forcing changes to the way networks have historically been operated and
managed" or something similar.
---------------------------------------------------------------------------
§2.3.2:
> The customer may need
> call customer care to find out the reason, both an inconvenience
> to the customer and additional overhead to the mobile network service
> provider.
I believe this is false. Please remove this assertion or support it with a
citation.
To my knowledge, standard operating procedure for mobile networks (based on my
personal experience on two different post-paid US carriers and probably half a
dozen pre-paid non-US carriers) is that users are sent an SMS message
explaining the situation. I think the statement above overstates the
inconvenience to both users and operators, and consequently runs the risk of
causing protocol designers to evaluate the impact incorrectly.
---------------------------------------------------------------------------
§2.3.4:
> Third parties use
> the inserted information for analytics, customization, advertising,
> to bill the customer, or to selectively allow or block content.
This is much improved over the previous formulation, but it leaves out a simple
factual statement that is highly relevant when designers are evaluating the
impact of encryption on this behavior. In fact, I would argue that it leaves
out the *most* notable use of these headers: cross-site user tracking. I
suggest amending the list to something like:
Third parties use the inserted information for analytics, customization,
advertising, cross-site tracking of users, to bill the customer, or to
selectively allow or block content.
---------------------------------------------------------------------------
§3.3:
> encryption approach described below. In most cases, solution have
> been identified to provide encryption while ensuring management
Nit: "...solutions have..."
---------------------------------------------------------------------------
§3.2.2 and §5.1:
Nit: s/SPAM/spam/g
Many thanks for all the effort that has gone in to addressing all the comments from the last IESG review and from the community. I find this version to be much improved from the last time the IESG reviewed it. However, I do not feel that I can support the publication of the document. While the tone has improved in many places and the introduction does a better job of contextualizing the document, the document still contains text in several sections that states service providers' claims about their practices as facts rather than stating them as claims or presenting the practices in a neutral way. This was a point raised in my previous DISCUSS (I've included my previous DISCUSS ballot text below in full for reference). In the previous review round Warren had invited recommendations for places where the tone or choice of words could be made more neutral or balanced, and I provided many detailed suggestions, but a number of those were not adopted. I also realize that the introduction contains much of the disclaimer text we previously hashed out to try to address this, but it doesn't contain all of it. So this is still a major issue for the document, IMO. The document also still extemporizes about future possible impacts, making it hard to come away with a neutral view of their treatment, as I noted in my previous DISCUSS ballot. I support the DISCUSS position held by Ekr. But given the above I don't think it will be fruitful for me to continue to engage on the details of this document, so I'm abstaining. I've included below some of the areas that I still find problematic, as well as some nits. Problematic areas: = Section 2.1.2 = (1) "Network operators are often the first ones called upon to investigate application problems" I still contend that without data to back this up, this claim should not be made, especially for the enterprise context. (2) "Vendors must be aware that in order for operators to better troubleshoot and manage networks with increasing amounts of encrypted traffic, built-in diagnostics and serviceability must be enhanced to provide detailed logging and debugging capabilities that, when possible, can reveal cleartext network parameters." If I try to paraphrase this it sounds like "vendors should build in capabilities to decrypt encrypted traffic." Was that the intent? = Section 2.2.4 = I agree with Christian Huitema's unresolved comments on this section. In the thread regarding his comments Kathleen said "we don't want to make general statements that aren't necessarily true" -- IMO that is what the middle three paragraphs in this section are doing. At a minimum, I think the characterizations about the effects of performance-enhancing proxies needs to be qualified by saying "some operators find that ..." rather than stating their effects as fact. = Section 2.2.7 = "There is work in progress to specify protocols that permit Service Function Chaining (SFC)." I don't think it makes sense to have this forward-looking statement when Section 1 states that "This document describes practices currently used by network operators to manage, operate, and secure their networks." I think it makes sense to focus this section on how existing SFC deployments have stopped functioning because of increased use of encrypted traffic, but it seems unfair to claim that some future, yet-to-deployed functionality will be broken. = Section 2.3.2 = "As a result, some mobile carriers block customer's encrypted requests, which is a far less optimal customer experience because the blocking reason must be conveyed by some other means." This could easily be read to imply that sending requests in cleartext is optimal. Overall, the use of the words "usual," "optimal," and "often" in this section imply a level of generality that is unwarranted I think. = Section 5.6 = The implications for SAVI seem speculative unless you can point to SAVI deployments that have been impacted by increased use of encryption. Nits: = Abstract = s/Pervasive Monitoring (PM) attacks on the privacy of Internet users is of serious concern/Pervasive Monitoring (PM) attacks on the privacy of Internet users are of serious concern/ = Section 2.1.2 = (1) "Further, the performance of some services can be more efficiently managed and repaired when information on user transactions is available to the service provider. It may be possible to continue such monitoring activities without clear text access to the application layers of interest ..." It's not clear what "such monitoring" refers to, since the previous sentence is about performance management and service repair. (2) Is "User/Service Key Quality Indicators" a term of art? It seems weird to be capitalized. = Section 2.2.3 = This section seems like it was left in the document by mistake. = Section 2.3 = "As previously stated, the intent of this document is to document existing practices, the development of IETF protocols follows the guiding principles of [RFC1984] and [RFC2804]." Is that comma supposed to be a period? I'm not following the grammar here. = Section 2.3.1 = s/However, the lack of ability to efficiently manage endpoints as a service reduces providers' ability to offer parental control./However, the lack of ability to efficiently manage endpoints as a service reduces network service providers' ability to offer parental control./ = Section 4.1.2 = It seems like a single reference to RFC 8250 would suffice. = Section 7.4 = What is a trusted transit proxy? ---------------------------------------------------------------- Previous DISCUSS ballot text: 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.