IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2015-12-03. These are not an official record of the meeting.
Narrative scribe: John Leslie and Susan Hares (The scribe was sometimes uncertain who was speaking.)
Corrections from: John
NB Alia Atlas joined after the roll-call; and an observer apparently also joined.
2. Protocol actions
2.1 WG submissions
2.1.1 New items
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
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
3.2.2 Returning items
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
1036 EST no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
7. Working Group News
1103 EST Adjourned
(at 2015-12-03 06:00:13 PST)
Could you explain a bit to me how prevention of leaf-to-leaf communication is enforced? I wasn't clear about that from a quick read, sorry. (I know it might not be quite in scope, being an implementation issue, but I'd like to know if it's easy to explain.) Are there possible attacks on signalling - e.g. to send fake packets saying some node is a root, when it's a leaf? If so shouldn't those be recognised in the security considerations? I think section 9 should describe the kind of node compromises that would invalidate the "no leaf to leaf" protections that are needed for this to work. The intent should be just to allow implementers to realise when a node that they are designing or deploying might need to be (better) protected against compromise. Were is possible to say something useful about how to mitigate such compromises, that'd be good too. (But it may amount to "harden your kit" I guess, which could be enough to say if one knows which bits of kit need hardening against what.)
Section 3. (Introduction) describes an E-Tree (as defined by the MEF) using rfc2119 keywords. While the use of the keywords makes the description clearer, I don't think it is appropriate to use them as the text is describing what is defined somewhere else. In other words, this document does not normatively define an E-Tree. If parts of the description want to be emphasized, please use other means (or other words). I don't think this comment raises to a DISCUSS level, but I think it needs to be addressed before publication.
- Section 3, first paragaph: This seems to use 2119 keywords to describe existing requirements from the referenced specification. Please avoid 2119 keywords for that (unless in the form of direct quotes). -9: Can you elaborate on how the prevention of leaf-to-leaf communication enhances security? As written, this seems to leave the actual enhancement for the reader to infer. - 4, last sentence: s/are/is
I agree with Ben and Álvaro about the use of 2119 key words to talk about something that's normatively specified in a MEF document and not here. Why does the first paragraph of the Introduction specifically mention MEF 6.1, with no reference provided? There is a reference to MEF 6.2 (but it's not cited here). Is something out of sync? And if so, why is there no citation in the Introduction? The MEF documents are cited in the Terminology section (with an incorrect citation to MEF6.1, which isn't in the references). That tells me that they should be normative references, as they're providing definitions of terminology that has to be understood... but you have them as informative references. Why? (This comment is very close to a DISCUSS, but I'm not balloting it that way.)
Sheng Jiang performed the opsdir review
I wonder if you've gotten wrapped around the axle here knowing that we won't standardise a (D)TLS MitM, but yet trying to describe things that basically are often deployed as MitMs. Anyway, while I do agree with Alissa's discuss, I also have some additional points to raise, some of which I think came up when we had some mail exchanges about an earlier version of this draft back in January of this year. (1) Alissa is correct that the unqualified SHOULD NOT "terminate" DTLS is insufficient, but in addition to her call for qualification of that, (or I guess moving to a MUST NOT,) I would like to chat about the consequences should one (for whatever reason) ignore that SHOULD NOT. Whether or not this discuss point is worth talking about depends on how Alissa's discuss on this is resolved. It seems to me (as I said back in January) that keeping the SHOULD NOT would mean that any UA that is able to inter-operate with a B2BUA that does "terminate" DTLS (because it fits with whatever qualifiers you end up adding to the SHOULD NOT) can never ever be confident of the identity of any DTLS peer (since it has code that lets the call happen regardless of the DTLS-layer peer identity). I can't see how that wouldn't make the Internet worse, hence the discuss. (2) In the introduction you say "B2BUAs terminating DTLS-SRTP session are outside the scope of this document." yet if you keep the SHOULD NOT and don't move that to a MUST NOT (which was an option we discussed back in Jan, I assume the WG didn't like that?), then you are in fact including those are within the scope of this document and therefore you would need to specify how to "terminate" a DTLS or DTLS-SRTP session when one is a B2BUA but yet respect RFC2804. I just can't see how one might do that to be honest. (3) 3.1.2 says: "There are two types of media-aware relays, those that merely inspect the RTP headers and unencrypted portions of RTCP packets, and those that inspect and modify the RTP headers and unencrypted portions of RTCP packets." Logically, those are not the only options, as one can modify the encrypted portions too. (Hopefully resulting in the integrity checking causing the packets to be dropped.) I think this particular lack of clarity does raise to the level of a DISCUSS as it's crucial for this document to be clear about not standardising a MitM. ("Sins of omission" are probably not a good idea here:-) (4) 18.104.22.168 says: "This security and privacy problem can be mitigated by having different keys for protecting RTP header integrity and encrypting the RTP payload. For example, the approach discussed in [I-D.jones-perc-private-media-reqts] can be used." I have two issues with that. First, where is having different keys documented? If only in the draft referenced, then what is the status of that? And secondly, doesn't perc require a KMS to exist? In which case I can't see how this specification works for calls between UAs (via a B2BUA) where there is no KMS. I think there are both security and interop (and hence also process) issues with what you're saying here. (5) 3.2 says: "the ClientHello message from a B2BUA (acting as DTLS client)" I don't see how a B2BUA can send it's own ClientHello (as opposed to forwarding a UA's) unless it is a MitM. Since we do not standardise MitM (cf. RFC2804) this text must be wrong or out of place?
- I don't see what Figure2 is trying to tell me, though the preceding text is clear enough. I'd recommend maybe dropping that figure or else making it a full ladder diagram of (most of) the messages involved. - There's a repetition of the "SHOULD NOT" problem that affects my point (1) above and Alissa's discuss points in the security considerations when you say "Attempting to cover media-aware relay modifying RTP headers and media termination scenarios involving secure sessions (like DTLS-SRTP) will inevitably lead to the B2BUA acting as a man-in-the-middle, and hence it is RECOMMENDED that B2BUAs do not terminate DTLS-SRTP session." - As with Alissa, I think the reliance on 4474, especially if that is not deployed, is odd. It would be bad if that were read as encouragement to not check DTLS client/server certs unless one implements 4474. (But this is covered in Alissa's discuss so is just a comment here.)
I like the idea of documenting the methods used for MiTM to provide ways to avoid that in practice, but support Alyssa'a discuss points to make this point more clear (purpose of this documentation) and her concerns about what happens in actual implementations. I'd like to hear more on whether this should be standards track or informational as well and will follow along with her discuss thread.
I support at least some of Alissa's and Stephen's DISCUSS points. In particular, I'm not fully in agreement with Alissa on her point 1: We do sometimes (and should) make normative statements about how protocols should work and should be used, even with knowledge that those statements may (will) be ignored. Sometimes it's to keep the protocol tight; sometimes it's to provide a lever ("The IETF has a standard that says that what you're doing is wrong!"). Because of that, Alissa's point 2 is particularly important: We have to stop the general practice of watering down normative statement in protocols as a way of mollifying people who don't like them. If the right thing is to say "MUST do X", we should not say "SHOULD do X" because we know that some implementations don't and won't do X. In particular, here, if there's any value in this, it's necessary to be strict and clear to expose that value.
(1) I have a fairly fundamental concern about this document that I'd like to discuss. My impression is that most B2BUAs in the market today that handle DTLS-SRTP do so with the explicit purpose of accessing the media. That is, if I need a box that doesn't access the media I use a SIP proxy, and if I need one that does access it I use a B2BUA. I realize that there are more flavors of B2BUA defined in RFC 7092, but in terms of how real SBCs work, it seems to me that they break DTLS-SRTP intentionally if they do so at all. If that's the case, the question then arises about the value of writing down normative recommendations that are more than likely to be ignored. Perhaps this document would have made more sense as informational, offering a non-normative explanation of what a B2BUA should do if it does not want to break e2e security. Even as an informational document it's still not obvious to me that there is much at all to say here for media-aware B2BUAs that isn't entirely reductive -- "don't terminate DTLS-SRTP if you don't want to break DTLS-SRTP" -- but at least as an informational document it wouldn't be suggesting normative requirements that are out of sync with real deployments. Could you articulate the reasons why someone would build a B2BUA that follows the recommendations in this draft? I note that the draft says nothing about using a TURN server as a media relay, which seems like it would be more common than using a B2BUA for the same purpose. Aren't B2BUAs typically deployed *because* they are media-aware? (2) Taking into account the above comment, I think 22.214.171.124 and 126.96.36.199 are problematic. 188.8.131.52 creates a normative SHOULD NOT-level requirement for inspection B2BUAs without explaining what the exception cases are, and 184.108.40.206 creates no normative requirements for modification B2BUAs. It's not even clear to me why the distinction is being drawn between the two kinds of B2BUAs if the bottom line is that in both cases the recommendation is to not terminate DTLS-SRTP. But this brings us back to the above comment. The problem here seems to be that what the WG and the IETF would want to say here is that B2BUAs MUST NOT terminate DTLS-SRTP to man-in-the-middle the media, but that is what B2BUAs generally do, so instead the text waffles and the recommendations are watered down and unclear. (3) The characterization of the RFC 4474 mechanism seems to contradict the way the mechanism is actually specified. The 4474 mechanism was designed such that intermediaries would be able to provide signatures on behalf of users (e.g., see RFC 4474 Section 3, "This specification allows either a user agent or a proxy server to provide identity services and to verify identities ... in the initial use of this mechanism, it is likely that intermediaries will instantiate the authentication service role"). So the claim that terminating DTLS-SRTP would cause 4474 identity and integrity checks to fail isn't true, because an SBC can decrypt and re-sign the request itself. A B2BUA that bridges two administrative domains can check the validity of the signature in the domain on on side as authorization to form a new signature that is valid in the domain in the other side. The fact that user-provided identity assertions are not guaranteed to persist end-to-end is one key reason for the ongoing work in the STIR WG. The work there and elsewhere shows that it's fairly widely acknowledged that 4474 has not seen the deployment that was hoped for when it was specified. Making its use a normative requirement here again seems out of sync with deployment reality. I would encourage you to review draft-ietf-stir-rfc4474bis and reconsider what security mechanism should form the basis of the recommendations in this draft.
Section 3.1.1: Is there anything new being specified here that isn't already specified in other SIP documents? Section 3.2: Is this saying anything that RFC 5763 doesn't already say?
Dan Romascanu performed the opsdir review
- section 5.1, first two sentences: The text can be interpreted to mean the subtree is the mechanism for that negotiation. I assume that's not the intent? -5.1, last sentence: I don't understand; what different tunnel? -8, paragraph 6: Do the 2119 keywords in this paragaph represent new requirements specified in this draft, or do they describe existing requirements from SNMPv3? If the latter, please use descriptive language rather than 2119 keywords. -5.1, Third sentence: Missing article before "Softwire mesh framework...".
As advised by the MIB doctors, draft-ietf-softwire-mesh-mib-04 (and draft-ietf-softwire-dslite-mib too btw) must be moved under mib-2
From Dave Thaler (MIB doctors) It does contain an number of typos and English grammar issues that should be addressed before publication. I put a marked up copy up where it should shortly appear as http://research.microsoft.com/~dthaler/draft-ietf-softwire-mesh-mib-12.pdf
needs work before progressing.
Thank you for doing this work. I have a small number of comments you might consider. In this text: Note: The above is chosen to match the TCP initial window of 4 packets, not the larger TCP initial windows for which there is an ongoing experiment. The reason for this is a desire to be conservative, since an RTP endpoint will also in many cases start sending RTP data packets at the same time as these initial RTCP packets are sent. Not to be pedantic, but it would be more correct to say "TCP maximum initial window of 4 packets". RFC 3390 describes this in TCP-speak as Equivalently, the upper bound for the initial window size is based on the MSS, as follows: If (MSS <= 1095 bytes) then win <= 4 * MSS; If (1095 bytes < MSS < 2190 bytes) then win <= 4380; If (2190 bytes <= MSS) then win <= 2 * MSS; If you end up making changes to this text, providing RFC 3390 as the reference for 4 and RFC 6928 for the experiment would make the reader's job easier. In this text: The above algorithm has been shown in simulations to maintain the inter-RTCP packet transmission time distribution for each SSRC, and to consume the same amount of bandwidth as non-aggregated RTCP packets. is there a reference you could provide for the simulations? In this text: The finality of sending RTCP BYE, means that endpoints needs to consider if the ceasing of transmission of an RTP stream is temporary or more permanent. I don't understand the subtlety of "more permanent" - is this "permanent"?
opsdir review was by Juergen Schoenwaelder
Thanks for helping me with my previous Discuss. I'm clearing, based on your proposed new text (modulo any changes that pop out of our continuing e-mail conversation).
opsdir review was by Juergen Schoenwaelder
- General: What'd happen if I used MPTCP with this? In particular with the multiple client i/f version. It should work I guess but I wonder if anyone's thought about any corner case issues (e.g. timing) that might come up? - section 4: "would be deleted" is too vague really - what did you want to see happen? - section 2: I don't get the last paragraph. What's that mean? nits: - General: There are many minor grammatical issues, e.g. cases of missing "an" or "the." It'd be nice to fix those before the RFC editor has to. - section 2: typo: "with with"
I don't have any substantive comments, but do have a number of editorial comments: - Abstract: -- The abstract seems unnecessarily long, can it be edited down? I suggest moving most of the text into the introduction and creating a much shorter abstract. -- 2nd paragraph, second sentence: "... using multiple interfaces requires to set up an IKE SA..." There appears to be a missing word after "requires". That is, requires _what_ to set up the SA? (Alternately, "...requires an IKE SA to be set up...") -- Please expand MOBIKE on first use (both in the abstract and in the body). - Section 2, 2nd paragraph after Figure 3: -- s/"In case of IPsec it means..."/"In the case of IPSEC, this means..." -- s/"drawback of such approach"/"drawback of such an approach" -- What does "transactionally" mean in context of "transactionally synchronized"? Is that different than just "synchronized"? -- s/"The drawback of such approach is that it requires new IKE SA"/"The drawback of such _an_approach is that it requires new IKE SA" - 2, third paragraph from end: "the VPN End User and the Security Gateway wants to move" s/wants/want -4, first paragraph: -- The language "The goal of the document..." makes it sound like there is a chance the document might fail to achieve the goal. I assume that is not the intent. I suggest reformulating along the lines of "This document specifies..." -- "without performing an authentication." without performing a _new_ authentication? - 5.2, 2nd paragraph from end: I don't understand the phrase "If the CREATE_CHILD_SA request concerns an IKE SA rekey ..." Maybe s/concerns/requests? -5.3, 4th paragraph: s/"In some cases responder..."/"In some cases, the responder..." - 8, third paragraph: Does this talk about resource exhaustion in general, or a resource exhaustion _attack_?
needs an editorial scrub for clarity, bens review is spot on.
- section 1, last paragraph: The first part of this paragraph sounds like justification for making this standards track. It would be useful to discuss why this is experimental. Is there an expectation some version of this may be republished in the standards track in the future? Is there a need for deployment experience prior to standardization? Editorial Comments: - Abstract: Please expand OLSRv2 on first mention in abstract. (In addition to the existing expansion in the body.) - section 4, 1st paragraph: s/metric/metrics
I agree with Kathleen's "Close to a Discuss" on warning about MitM attacks. I'm fine with actually addressing the attacks being out of scope, as I believe Kathleen is.
This is just a comment as the text is mostly there, but I feel like it could be stated more clearly... In the Security considerations section, the first part of the discussion could call out "Denial of Service" attacks explicitly in addition to the description that is included that describes altering traffic patterns. I would recommend making this a distinct paragraph for readability. The next part of the security considerations section (starts with the last sentence of the first paragraph) seems it could also be a result of the lack of integrity protections on this measurement technique. It might help to state that first and that active attacks may result as a consequence, leaving in the active attacks you already describe and the solution already included starting with the second sentence of the second paragraph. If that's not the case, please just let me know why. How is warning about MiTM attacks out-of-scope? It seems these are possible, and even mentioned with rogue routers. Wouldn't it be easier to state that without session encryption, MiTM is a threat? If this is acknowledged, then at least the consideration is there for the reader to understand. Addressing the threat may be out-of-scope, but warning about it shouldn't be. This last comment is much closer to a discuss, so I'd appreciate a response. Thank you!
Liushucheng (Will) performed the opsdir review.
Apologies for changing to DISCUSS after my initial NO OBJECTION position, but I just realized an implication to my comment about copying the IKEv2 text: The shepherd's write up says "[Informational] is the proper type of RFC because the document describes implementation recommendations for a proposed standard and is not a proposed standard in itself.". But this document does not merely make recommendations; it claims to stand alone as a full specification of everything needed for a minimal implementation that works with IKEv2. I'd like to discuss why this should not be standards track, as it's currently written.
I question the choice of copying IKEv2 text forward into this document, at least without clearly marking (and citing) the copied text. What happens if 7296 gets updated or obsoleted? It seems like that would effectively fork the protocol. And since this draft does not seem to distinguish copied text from new text, I wonder if the other authors of 7296 should be considered authors of this document.
I agree with Ben's question about copying text from a normative reference without clearly tagging it. Clear tagging seems like a good idea.
Thank you for this well-written and much needed document.
Nit that I'm sure the RFC editor would have caught: Last paragraph at the bottom of Page 4, so is repeated: "Minimal implementations only need to support the role of initiator, so so it" I'm fine with this being informational since it just describes a proof of concept implementation specific to lwig use cases of an existing standards track RFC. It does explicitly state that the referenced RFC is normative and any updates to that RFC would likely not apply to this one unless an updated POC is done and that might mean a new draft (I suspect).
I agree with Ben's DISCUSS ballot. It seems to me that this document is an Applicability Statement for 7296.
Tim Wicinksi performed the opsdir review.
Just a couple of editorial comments: - section 1, first paragraph, 2nd sentence: The sentence is confusing, and may suffer from an editing or copy-paste error. I'm not sure what "costly at the risk" of means. Also, who "generally admits" this to be true?
I support Alia's Discuss. I see that there's proposed text to resolve that position. I will remain a No-Objection if that proposed text is adopted, but I would be more comfortable if the proposed text was more specific than "may not work properly" - is there anything else that can go wrong, besides unbounded looping?
Thank you for addressing the SecDir comments and expanding the Security considerations section.
Thank you for a clear and well-written document. I have one point that is peripheral to most of the draft. In Section 4.3, it says: " In addition, for any other applications that generate intra-subnet traffic with TTL set to 1, these applications may not work properly in the Virtual Subnet context, unless special TTL processing for such context has been implemented (e.g., if the source and destination addresses of a packet whose TTL is set to 1 belong to the same extended subnet, neither ingress nor egress PE routers should decrement the TTL of such packet. Furthermore, the TTL of such packet should not be copied into the TTL of the transport tunnel and vice versa)." The idea of not decrementing TTL is quite concerning. I can conjecture cases where there is a routing loop between the relevant PEs - during reconvergence when a host moves from one datacenter to another is a trivial case. One approach may be to ask why a packet would have a TTL of 1 and determine if this case must be resolved. Another might detecting a loop back to an out-of-datacenter PE and dropping the packet. I'm sure you can develop other good ideas and solutions.
Jouni Korhonen performed the opsdir review.
reasonable to me modula Alissa's question.
I strongly agree with both Ben and Kathleen. The abstract reads as if the IETF has reached a consensus position, which is not appropriate for an ISE document.
I'd also like to discuss this one some more. So far, I've looked quickly at the diff between the last one we reviewed and the latest version. That's . That diff absolutely does not convince me that the draft is now only describing something already deployed. For example the latest one still says "...intended to allow broad deployment of the mechanism on the public Internet." That remains entirely inconsistent with IETF BCPs and so I believe we should revert to the previous DNP response to the ISE. If we reach consensus on that, then I'm not sure if we should try to identify all the "badness" in -07 or if we should just say "please DNP, no material change from our POV." I think the latter is more appropriate but maybe this is something we ought discuss with Nevil - what's the right/best kind of IESG response in such a situation. Which leads me on to... Also - from the ballot it's not possible for an AD to determine anything about why the ISE has returned this item. I think that is also something about which it'd be good to chat with Nevil, from a possible tooling POV but also from a transparency and accountability perspective. I think when/if the ISE is interacting with the IESG in cases like this, it would seem fairly obviously beneficial if the ISE's perspective on what's changed was part of the record. (Or perhaps the ISE's editorial board, I don't even know which applies.) The history of this overall set of documents and their authors' doggedness in attempting to achieve publication as an RFC (which is an entirely reasonable thing for authors to do) would seem to indicate that we ought carefully consider if we're collectively (IETF+ISE+RFCed) sending a message that all one has to do is keep asking and you can get any bad idea out as an RFC. I think we do not want that perception to spread.  https://www.ietf.org/rfcdiff?url1=draft-williams-exp-tcp-host-id-opt-05&url2=draft-williams-exp-tcp-host-id-opt-07
I'd prefer the abstract to read less like an IETF endorsement of identifying hosts behind NATs. (But not so strongly to block things, given the updates.)
I agree with Ben's point, especially in light of the described use cases. Although this is just documenting what happens, it would be best if this does not sound like an endorsement of these practices.
The authors have added text in Section 8. Pervasive Monitoring Considerations that addresses aspects of RFC 7258. Plus added statements about what of what not should be used in the HOST_ID part.
I'm not really sure how this is supposed to work when we change conflict review responses, so forgive me if I've balloted incorrectly given my comments below. Basically I don't think the document has fully resolved the issues raised in the previous conflict review. But I'm not arguing that the document conflicts with work in TCPM. I think the way that this spec justifies the design decisions that may allow the HOST_ID option to be used for pervasive monitoring can be summarized as: the option merely puts back in host identification information that a middlebox otherwise would have stripped out. I don't think this is really satisfactory. RFC 7258 doesn't say that we will work to ensure that pervasive monitoring remains only as easy or hard as it was before the deployment of CGNs or application proxies. It says that we will work to mitigate pervasive monitoring. So from the perspective of mitigating PM, the loss of unique host identification on the egress side of address-sharing devices is a virtue. Of course, the motivations for re-introducing host uniqueness are well-documented. But this draft doesn't link the specification of the option to those motivations in a way that provides the justification that RFC 7258 requires, IMO. In particular, the document allows for the HOST_ID to contain an IP address or subnet, optionally together with a TCP port number. Under some circumstances using the option in these ways leaks information that allows for correlating the activities of the host more broadly than if the option were not used -- e.g., if an application proxy uses the option in this way, then the host traffic on the egress side of the proxy can be newly correlated with the host's traffic that does not pass through the proxy. If instead the proxy used a random, locally unique ID in the option, this type of correlation would not be re-introduced. So why should the option support embedding an IP address and TCP port, if all it needs to provide is local uniqueness for the hosts sharing the public address? Doesn't an opaque locally unique ID suffice for the three use cases listed in the document?