IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2014-02-20. These are not an official record of the meeting.
Narrative scribe: John Leslie, Susan Hares, Nagendra Kumar, and Carlos Pignataro (The scribe was sometimes uncertain who was speaking.)
Corrections from: Benoit
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
1257 EST break
1303 EST back
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. Agenda Working Group News
Amy: BoF needing chairs
1336 EST Adjourned
(at 2014-02-20 07:30:06 PST)
4.3: If the PCP client fails to contact a given PCP server, the PCP client SHOULD clear the prefix(es) and suffix(es) it learned from that PCP server. What constitutes "fails to contact"? Is there some timeout involved there? And I'm not totally clear on why I'd clear the list just because I "failed to contact" the server. Could you explain?
- general: Is there any case where a bad actor could use this multiple times (say after reboots/resets that are visible to the ISP) getting different answers each time and thus being able to infer that some prefix similar to one received is now topologically nearby the bad actor? E.g. if I see Prefix#1, then reboot, wait a while and next see Prefix#1+10, I might conclude that 9 other nearby home gateways have rebooted perhaps and try use that for nefarious purposes. Can we think of any such nefarious purpose? I can't, hence this not being a discuss:-) However, if there were such a nefarious purpose, maybe it'd be worth some advice to deployments about making the prefixes unpredictable? (Just wondering.) - general: More friendly to DNSSEC? Fantastic! - 3.2.1: can a host synthesize AAAA records sufficient to verify all DNSSEC? Just wondering, but I'd have guessed some more detail might be needed. Is there really enough specified here? - Fig 1: Adding a "See Figure 2" below the IPv4 Prefix List would be clearer. - 4.3: I wasn't clear what an invalid prefix might be here - do you mean a bogon, such as 10/8? (Sorry, maybe I was reading too quickly.)
The abstract would read better (IMHO) if you used the same terminology as in the title of the draft: This document provides the offer/answer considerations for the G723 Annex A and the G729, G729D and G729E Annex B parameter when the value of the Annex A or Annex B parameter does not match in the Session Description protocol (SDP) offer and answer. It's good to see this work happening—thanks for doing it!
- I think a reference to RFC 6562 in the security considerations would be useful. - Based on 6562, I also wondered if it'd really be better for the defaults to be turned around from missing==yes to missing==no? Even if that's not feasible, were it desirable, it'd be worth noting.
-- Section 3 -- This came at me from out of the blue when I read it. What does it have to do with Annex A or Annex B? You talk about comfort noise frames in here, without any other mention of them in the document. What is Section 3 here for? -- Sections 3.1 and 3.2 -- This is purely an editorial point -- I think you're saying, technically, what you need to say -- but I find these two sections to be rather convoluted. I think, for example, this specifies the same thing, more clearly and concisely: NEW (Section 3.1) When a G723 offer or answer lacks an "annexa" parameter, "annexa=yes" is implied. When a G723 offer and its corresponding answer both specify or imply "annexa=yes", then G723 is negotiated with "annexa=yes". Otherwise ("annexa=no" is specified in either or both of the offer and answer), then G723 is negotiated with "annexa=no" END Is there really a reason for the rest of the wordiness, which I think actually comes across as confusing?
This document needs some work: Section 2: - Please add something along the lines of, "The 'Reserved' field MUST be set to 0 and MUST be ignored by receiving implementations." - Please add something like, "The 'Length' field contains the length, in octets, of the 'Description' field. It MUST NOT exceed 1016. (See section 3.)" - I am utterly mystified by, "The description text MUST NOT be null terminated." If you wanted to say, "The description MUST NOT contain *any* null (U+0000) characters" because you don't want to confuse things that will accidentally treat the middle of the string as the terminator, I might get it. But if you're going to allow internal ones, I don't get why you care whether the description has a trailing null. If that's what the client wants, what does the server care?
Section 3 gives a bunch of local implementation details as if they were spec requirements. You can't possibly require what the PCP server will do internally with this stuff. Please rewrite the first four paragraphs with the following suggested text: The DESCRIPTION option is OPTIONAL for both PCP servers and PCP clients. This option (Code TBA, Figure 1) MAY be included in a PCP MAP/PEER request to associate a description with the requested mapping. A PCP server MAY ignore the DESCRIPTION option set to it by a PCP client. (It can either simply not support the option, or it can be configured to ignore it.) To signal that it has not accepted the option, a PCP server simply does not include the DESCRIPTION option in the response. If the PCP client does not receive a DESCRIPTION option in a response to a request enclosing a DESCRIPTION option, this means the PCP server does not support that option or it is configured to ignore it. If the DESCRIPTION option is not included in the PCP client request, the PCP server MUST NOT include the DESCRIPTION option in the associated response. Paragraphs 5 & 6 try to put limits on the internal buffer sizes of the server, and give no indication of the reason for the length limits. Please rewrite as follows: Because of the UDP payload limit of 1100 octets, the Length of the Description MUST NOT exceed 1016 octets. The suggested maximum length is 128 octets. If a PCP client includes a DESCRIPTION option with a length exceeding the maximum length supported by the PCP server, only the portion of the Description field fitting that maximum length is stored by the PCP server and returned to the PCP client in the response. Paragraphs 7 & 9 again try to specify internal behavior. Instead: If the PCP client request contains invalid DESCRIPTION options (e.g., the content is not a legal UTF-8 string), the PCP server MUST ignore the request (i.e., MUST NOT return a DESCRIPTION option in the response). [Paragraph 8 is fine] The PCP client uses empty DESCRIPTION option (i.e., Length set to 0) to erase the description text associated with a mapping. To indicate that the PCP server has successfully cleared the description text associated with a mapping, the PCP server returns back the empty DESCRIPTION option in the response.
- "o Etc." is not a good bullet in a PS - "SHOULD NOT be used to leak privacy-related information" is pretty lame really isn't it? Who do you know that would set out to "leak privacy related information"? Perhaps giving some better guidance, e.g. say to not use customer IDs or names or PII or addresses or locations, would be easy and worthwhile? - On Pete's null terminated issue and the resulting mail threads. I assume that the authors know that mid-string null's have been used as part of deliberate attacks against PKI? So there are security reasons as well as interop reasons for not wanting nulls anywhere within strings. Not worth a discuss, but maybe worth a note.
Thanks for addressing the OPS-DIR feedback.
It looks like Pete's DISCUSS point about the NUL termination is resolved; that works for me.
I have no objection to the publication of this document, but I do support: 1. Pete's (and Stephen's) points on the null character 2. Pete's Comments on implementation details in Section 3 3. Stephen's Comment on needing better/more privacy discussion related to the DESCRIPTION field
From section 4.2: As specified in Section 3.2 of [RFC7104], it is advisable that the SSRC listed first in the "a=ssrc-group:" line (i.e., SSRC of 1000) is sent first, with the other SSRC (i.e., SSRC of 1010) being the time- delayed duplicate. This is a rather odd thing to say, given that the text goes on to say that it doesn't really matter. Either it matters or it doesn't. If it doesn't, you might want to say this instead: Section 3.2 of [RFC7104] states that it is advisable that the SSRC listed first in the "a=ssrc-group:" line (i.e., SSRC of 1000) is sent first, with the other SSRC (i.e., SSRC of 1010) being the time- delayed duplicate. If this is stated in anticipation that some implementations will erroneously take the order from the ordering of the two SSRC lines, then you might as well just require them to be specified in the intended order.
I agree with Benoit that the Abstract (and I think second paragraph of the intro) should be rewritten to indicate that this technique is only applicable to non-congestive packet loss. In the intro, one additional sentence would have helped me. After this: One technique to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. Add: As described later in this document, the probability that two copies of the same packet are lost in cases of non-congestive packet loss is quite small. In fact, nowhere in the document do you actually say something along the lines of "the techniques we describe actually address the kinds of non-congestive losses we see in the field." When chatting with Richard, he suggested some text like: Time-delay duplication and spatial duplication deal with different patterns of loss. Time-delay duplication helps with transient loss (within the duplication window), while spatial duplication can help with longer-term loss that affects only one of the two redundant paths. Saying that, and saying, "Those are the kinds of losses we actually see, so these techniques will help" would be useful.
- Please see the additional security considerations text added to  version -03  after my discuss on that. I'm not sure that text is prefect but isn't something similar warranted here too? (And since we've common authors, this should be easy enough:-) Doing that by reference is fine if that's easier. - BTW: I thought I was reading the same document as  for a while;-)  https://datatracker.ietf.org/doc/draft-ietf-mmusic-delayed-duplication/  http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-delayed-duplication-03
thank you for the considerations on congestion control!
I want to talk about this on the call on Thursday. Like others (incl. Suresh) I am concerned about Section 7 language. It is important that the section indicates who the MUST/SHOULD requirements are placed at, and how those entities know the situation. One interpretation is that the requirements are placed on operator (the human). In that case, maybe some language such as "The network operator MUST NOT …" should be used. On the other hand, if you are talking about things that devices should do, they have no knowledge of congestion, as Suresh pointed out in his Gen-ART review. In this case I'd recommend a change along the following lines: OLD: Duplication is RECOMMENDED only to be used for protection against network outages due to a temporary link or network element failure and where it is known that there is sufficient network capacity to carry the duplicated traffic. NEW: Duplication is RECOMMENDED only to be used for protection against network outages due to a temporary link or network element failure and where it is known (e.g., through explicit operator configuration) that there is sufficient network capacity to carry the duplicated traffic.
Not a DISCUSS, but I would appreciate of this one would be solved. I believe the abstract is misleading: Packet loss is undesirable for real-time multimedia sessions, but can occur due to congestion, or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document explains how Real-time Transport Protocol (RTP) streams can be duplicated without breaking RTP or RTP Control Protocol (RTCP) rules. The abstract tells me: here is mechanism to avoid packet loss, which can occur due to congestion of other unplanned network outage However, from section 7: First of all, RTP duplication MUST NOT be used in cases where the primary cause of packet loss is congestion since duplication can make congestion only worse. So this spec. only applies to "other unplanned network outage". This should be clear from the beginning, i.e. the abstract. Interestingly, this is in line with my DISCUSS on draft-ietf-mmusic-delayed-duplication-02. At least, I'm consistent with myself. Thank for addressing Linda's and David's OPS-DIR reviews
This loss might be due to congestion, it might also be a result of an unplanned outage caused by a flapping link, link or interface failure, a software bug I just have an amusing image of Martian packets on a flapping link. Don't mind me....
I'm supporting Benoit's Comment about being clear that the intended environment is managed/engineered networks, early in the document.
I have a number of comments below, and an overarching concern. The over arching concern is the assumption that using different flow identifiers will cause the use of diverse paths, and this is by no means assured. If you want diverse paths we should look at methods of implementing that such as segment routing and MPLS TE. ===== From a routing perspective, two streams are considered identical if the following two IP header fields are the same, since they will be both routed over the same path: Not really, we look at the IP type and transport ports to determine flow equivalence. ===== When two routing-plane identical streams are used, the two streams will have identical IP headers. This makes it impractical to forward the packets onto different paths. Er well they could have different flow labels. ======== Due to the possible presence of network address and port translation (NAPT) devices, load balancers, or other middleboxes, use of anything other than an identical 5-tuple might also cause spatial redundancy ... and flow label ======== When using spatial redundancy, the duplicate RTP stream is sent using a different source and/or destination address/port pair. This does not guarantee spacial redundancy of course.
I just so wish you hadn't made this "LDP" it shares so little with LDP that you might just as easily have made it a whole new protocol and saved all of the baggage and the strangeness that *will* happen when an implementation gets confused and sends a regular LDP message trying for a label. Indeed, the whole document basically fails to discuss how this fits within LDP in terms of session establishment etc. Thus, I think there is an assumption that there is already an MPLS LDP session between each pair of PEs in an RG such that the elements of this protocol can just piggy-back on that. Indeed, section 4.6 presents a hack for a "separate" session without saying separate from what. In the case where no labels exchange is needed between the PEs, this would be the normal case and it indicates that LDP is not really the best choice for this approach. However, "I think this way of doing things sucks" is clearly not a reason to place a Discuss or to block the document. It is also clear that this approach has been coded and shipped. I think it's a shame it wasn't done cleanly and I am surprised that LDP architects and the PWE3 WG didn't think this an unnecessary hack. --- I think Tom may want to change his coordinates --- I think that new LDP-based documents would do well to include references to further work on MPLS and LDP security. In particular, RFC 5920, RFC 6952, and draft-ietf-mpls-ldp-hello-crypto-auth.
This draft says that some kind of "transport security" is required, but does not seem to say precisely what that means, nor does it say how to implement anything meeting the requirement. And the protocol does involve sensitive operations on non-colocated nodes, so I think a bit more work on the security issues is needed. Presumably that will mean clarifying assumptions made (e.g. that all connections, local or remote are somehow "secure") and providing better references to existing mechanisms that can be used, so I'd like to DISCUSS that. I've broken that down into four parts below to help move that discussion along more quickly, but depending on the answer to point (1) in particular, it might turn out to make sense for me to restructure the discuss points, so we should I guess focus on that point first. (1) 3.3: What does "transport security" mean in requirement vii? (2) section 4: which layer handles "transport security"? How can that be done? (3) 10, para 2: "MUST provide a mechanism" does not say what mechanism - how can this be implemented and achieve interop? (4) 10, para 3: "SHOULD provide mechanisms" does not say what mechanism - how can this be implemented and achieve interop?
- 7.2.4 - what is an "LACP Actor Key"? Sorry, I just don't know:-) Is that an identifier for a thing or a cryptographic key? I assume the former.
A quick scan for things of high-layer interest, so apologies if these are off the mark. If these comments were on an application-layer protocol, I'd probably want to DISCUSS them. But I hope you take them to heart nonetheless. 6.2.1: - Sender Name Hostname of sending device encoded in UTF-8, and SHOULD NOT exceed 80 characters. Is this a hostname in the sense of a DNS host name? Do you really want those in UTF-8? Are you wanting U-Label IDNs in there? Seems a bit worrisome. Also, do you mean 80 characters, or 80 octets? 80 characters could be significantly more than 80 octets. 18.104.22.168 and 22.214.171.124: - Disconnect Cause String Variable length string specifying the reason for the disconnect. Used for network management. That in any particular encoding? US-ASCII? UTF-8? Does it matter? 126.96.36.199: - Service Name The name of the L2VPN service instance encoded in UTF-8 format and up to 80 character in length. Do you mean 80 characters, or 80 octets? 7.2.4: - Aggregator Name Aggregator name encoded in UTF-8 format, up to a maximum of 20 characters. Used for ease of management. Do you mean 20 characters, or 20 octets? 7.2.5: - Port Name Port (interface) name encoded in UTF-8 format, up to a maximum of 20 characters. Do you mean 20 characters, or 20 octets?
For what it's worth, not remotely my area of expertise and I'll rely on people who understand this better to carry out the conversation, but I had assumed that this was a fairly straightforward extension of LDP and am bemused to understand that it's not.
Updated... Having read Adrian's comments, I re-read the specification and concur with his concern. Overloading existing protocols can lead to problems. I can envision future work where either the ICCP function or the LDP function needs to change its core behavior. It is quite possible that the requirements for the other function will interfere with making such changes. Given the nature of ICCP, it seems to me that a better design decision would have been to make it a separate protocol. For the IESG... I equate this with the recent discussion we had over the ICMP AUP draft. Overloading existing protocols because they have similar semantics or functionality is not good protocol design.
In section 2.2, right after the caption for Table 1, the following text appears: Other options suggested for 0: PKIX-TA It appears that this is what is actually in the table, so this text makes no sense.
This is a purely administrative point for the IESG. It will not hold up publication for even a nanosecond. Let's make this "Informational", shall we? Nothing requires that this be standards track, and the odds that it will advance are zero. (And before you say that it "Updates" a standards track document or that it is "changing a registry defined by a standards track document", I'd like a citation of somewhere that says that you can't do that with an Informational document.) If the IESG agrees and we change the status, I will clear immediately. If not, I will not stand in the way of publication at all and simply Abstain, no hard feelings at all.
I am fine with changing this to Informational.
I would support either document class ("don't care").
I agree with Pete's point that this should be an Informational document.
Please expand DANE and TLSA on first use.
This is a question, not a request for a text change. In section 4. Long Command Lines (Update to RFC 2683), does this work because the only implementations using command lines longer than 1000 bytes are using them to implement this spec? I wasn't completely comfortable updating RFC 2683 in a document that's mostly defining new extensions, wondering if that update would be visible enough to implementers who weren't reading this spec. I'm just majing sure I'm wrong about that ...
Holding a Discuss for IANA. Will move to Yes ballot when IANA is/are happy.
- I have to say that I found this pretty hard to comprehend (whilst speed reading mind you;-). That's probably just me, but I do wonder if others who aren't involved in the WG have found the same or not. - table 4, values 1 and 2 have the same text - seems odd
Very easy-to-fix DISCUSS: - section 4.1 An implementation MUST NOT reject a message because it contains such a TLV. "such a TLV" is described in the intro text of section 4.1 This sentence is key: this is THE specification, as it contains a MUST, and therefore must be self-contained. Please make clear. For example: An implementation MUST NOT reject a message because it contains a unrecognized TLV value.
This document updates the specification of the protocols [OLSRv2] and [RFC6130]. As such it is applicable to all implementations of these protocols. What does the second sentence add? Isn't it obvious if this document updates [OLSRv2] and [RFC6130]? Maybe I'm missing a subtle concept?
-- Section 5.1 -- The descriptions of Tables 4 and 5 have some similar wording, which I can't make sense out of: For all future allocations, the Expert Review MUST ensure that allocated bits MUST use the unset bit (0) to indicates no information, so that the case Value = 0 will always indicate that no information about this network address is provided. Can you explain what this means, and perhaps come up with clearer wording? I honestly have no idea what you're trying to say, and as it's a "MUST", that seems important.
I have no objection to the publication of this document, but I have two points that need discussing. These should be easily addressed. 1. Section 4 has the following text: "This specification describes how NHDP [RFC6130] and OLSRv2 [OLSRv2] SHOULD handle TLVs with other TLV Value fields." I am not sure why there is a "SHOULD" here. *If* there was a need for a 2119 keyword, I believe a "MUST" is in order. However, I don't think a 2119 keyword is needed at all. I suggest replacing that sentence with: "This specification describes how NHDP [RFC6130] and OLSRv2 [OLSRv2] handle TLVs with other TLV Value fields." 2. In Section 4.3.1, the text talks about creating an IANA registries to manage the allowed values in the various TLVs. The second paragraph then says "An implementation of [RFC6130], receiving a TLV with any TLV Value other than those values used in that specification, MUST ignore that TLV Value and any corresponding attribute association to the address." Shouldn't the guidance be that values not in the *registry* are ignored?
Section 3, first paragraph: include it. However inclusion of this optimization is advised, it can, in some cases, create smaller and fewer messages, without ever having the opposite effect. This is nitpicky, but I wish you'd use some conjunction other than a comma between "advised" and "it" on the first line, or else make it two sentences.
These two statements seem in conflict: A set of routing MPRs created as specified in [OLSRv2] MAY be optimized in the following manner. [...] It is RECOMMENDED that all OLSRv2 routers use this optimization. The first indicates that the optimization is purely an option. The second indicates that it is a requirement with certain exceptions that may exist. Which do you mean? If the former, I'd suggest just getting rid of both of the 2119 terms (use "can" instead of "MAY" and "suggested" instead of "RECOMMENDED"), since it's only a suggestion. If the latter, change the "MAY" to a "SHOULD".
- I read multiple times these sentences, and I'm not sure what they mean: Note that an implementation using this optimization is not strictly compliant with the current specification [OLSRv2], ... This specification updates [OLSRv2] to specify that an implementation using this optimization is compliant with the protocol OLSRv2. - I agree with Barry's DISCUSS - I Would appreciate if you would expand MPRs (multipoint relays) earlier in the draft.
I'm raising Pete's comment to a DISCUSS: the conflict between the MAY and RECOMMENDED in Section 4 isn't just an editorial thing... it really is conflicting normative language that has to be resolved. I know that the authors are dealing with this, so there's no need to respond here. I'll clear when Pete's comment is resolved.
I'm impressed: a Standards Track document that goes into IESG Evaluation with a -00 version. I look forward to the day when there's an extension to optimize this optimization of the Optimized Link State Routing Protocol. Just sayin'.
I'm No Objection, and trusting that the fuzziness other ADs are asking about will get unfuzzed ...
Since other ADs have already raised the issues I spotted with this document, I will simply point out that the MPR acronym needs to be expanded and should not appear in the Abstract.
The last paragraph of Section 1 begins: In order to use the mLDP in-band signaling procedures... ...but "the mLDP in-band signaling" is a new term. It turns out that it meas exactly what the previous paragraph ended up saying, viz. encoded into the mLDP FEC element. So I suggest that you update the end of the previous paragraph to read encoded into the mLDP FEC element in what this document terms "mLDP in-band signaling."
It seems kind of incredible that the security considerations here are so simple, when we're glueing together two different ways to do multicast. Surely at least the security considerations relevant to PIM ought be noted? Would it (un)fair of me to guess that perhaps nobody has really looked for potential new vulnerabilities here? As it happens, I don't have the time before the telechat, nor probably the MC clue, to help with that so this is not a DISCUSS, but you could set my mind at rest if you told me that yes, a bunch of folks with that clue and some security clue have really spent time looking at this.
No objection, and no complaint at all here... just an observation: I find it interesting that an 11-page document has six authors.
I have a general concern, but I am not sure if it is the fault of this document, RFC 6513, or RFC 6826 so let's discuss it here for the time being... How are non-global-scoped IPv6 multicast addresses handled? There is no discussion in this document about verifying that the creation of an MDT is not violating a scope boundary. RFC 4007 (section 10) is very clear on the rules that must be followed when creating forwarding state. If these rules are not followed, scoped packets can leak out of their allowed zone creating a vulnerability. Notionally, I would have expected to see something in Section 2 saying that scopes need to be checked as a part of the signaling procedure. There does not appear to be any discussion of scoped addresses in 6513, 6512, or 6826. Where in the MPLS VPN specs is support for scoped multicast addresses defined?
I have no objection to the publication of this document, but note a few things that probably need to be fixed. === Section 1 says... In particular, it defines a MIB module ...but there are three separate MIB modules in this document. --- Section 4. It would be helpful if you noted what the arrows in Figure A imply. --- RFC 3411, RFC 2863, and RFC 3813 are all used as normative references in Section 6.1, so you should move them to Section 9.1. --- VPLS-GENERIC-MIB has vplsGenericDraft01MIB MODULE-IDENTITY ...which looks like a bit of broken cut and paste and several REVISION/DESCRIPTION clauses which I believe are only meant to reflect revisions of the module published in RFCs. This applies to the other modules as well. --- The REFERENCE clauses don't appear to be formed correctly. For example: REFERENCE "[RFC4364]" I think that you are not supposed to use citations in the MIB modules (because the module may be sucked out of the RFC and so appear without the references), and I think the approved form for references: - gives the RFC number - names the RFC by title - gives a section number where possible Similarly, the DESCRIPTION clauses shouldn't use citations, but can simply use RFC numbers. ---- Surely VplsBgpRouteDistinguisher and VplsBgpRouteTarget should say how the protocol things are encoded into the TCs even if only to say that the encoding matches what is used in BGP. --- Probably a pathetic comment, but shouldn't you at least note that vplsConfigFwdFullLowWatermark must be less than vplsConfigFwdFullHighWatermark. I think that less-than-or-equal-to doesn't work, does it? And given that, isn't it the case that vplsConfigFwdFullHighWatermark should have range 1..100, and vplsConfigFwdFullLowWatermark have range 0..99? --- At http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security there are guidelines about what to put in a MIB document's security section. I am a little surprised that your MIB Doctor let you get away with what you have here, but I'll leave it to the OPS and SEC ADs to worry about whether anything needs to be done.
Thanks Benoit for handling the security considerations boilerplate issue. Feel free to ping me if some help with getting that sorted is useful.
Easy to fix DISCUSS. Secure SNMP in the security considerations? You surely mean SNMPv3. The security considerations must be aligned with http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security.
Private IESG joke: Adrian took care of the MIB review, I took care of the Security Considerations, Stephen/Sean, can you please take care of the OPS issues :-)
no objection on the assumption that the two comments present (benoit adrian) will be addressed.
Thanks for a well-written document. As pointed out by Vijay in his Gen-ART review, in Section 6, In some situations, returning very detailed error information (e.g., over-range measurement or measurement unavailable) using this report block can provide an attacker with insight into the security processing. Implementers should consider the guidance in [I-D.ietf-avt-srtp-not-mandatory] for using appropriate security mechanisms, i.e., where security is a concern, the implementation should apply encryption and authentication to the report block. the text does not really describe what security issue is being an issue here. I also read draft-ietf-avt-srtp-not-mandatory, but it did not talk about this specific issue. In the e-mail discussion a brief mention of the rational was given. I think it would be useful to add some text here. But this is an editorial issue, not a blocking-level comment.
I put myself in the shoes of the operator looking at the different extended reports, and I'm trying to understand how to correlate the number of discarded bytes with number of discarded packets from the different extended reports. From the document, there could be 3 different extended reports reporting the number of discarded packets: o Reporting the number of discarded packets in a measurement interval, i.e., during either the last reporting interval or since the beginning of the session, as indicated by a flag in the suggested XR report [RFC7002]. If an endpoint needs to report packet discard due to other reasons than early- and late-arrival (for example, discard due to duplication, redundancy, etc.) then it should consider using the Discarded Packets Report Block [RFC7002]. o Reporting gaps and bursts of discarded packets during a measurement interval, i.e., the last reporting interval or the duration of the session [RFC7003]. o Reporting run-length encoding of discarded packet during a measurement interval, i.e., between a set of sequence numbers [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics]. First of all, it would be nice to mention that the measurement intervals from the different extended reports are synchronized. Talking to Dan Romacanu (btw thanks Dan), I understand that the number of bytes can be correlated to the number of packet in bullet 1 (RFC 7002) and/or in the bullet 3 ([I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics]), depending on the flag value expressing whether we speak about delta or running counters. A few sentences (or a new section) about this would be an extremely useful addition from an operational point of view. Note: it was confusing to me that [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics] refers to http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06, a very old version of the draft ... which still contains the bytes extended report. Mentioning RFC 7097 obviously solves that one. Thanks again Dan for gently highlighting the obvious to me :-)
-- Section 7.3 -- In the discussion of draft-ietf-xrblock-rtcp-xr-synchronization, Pete brought up the question of using an individual as the contact point for working group stuff. I suggest that this document should use the same resolution as that one, specifying the RAI ADs <email@example.com>.
Again, I wonder if the IANA registration should point to other than an individual.
This should be a quickly resolved discuss. I don't agree with the security considerations section here. Has someone checked in any detail to see if these offsets can assist a potential timing side channel attack? (I'm guessing not.) This has been a common question for xrblock documents, so I think there's text in other recent RFCs, but in this case I think the potential attack could be more realistic. (That is not covered in 3611 btw.) For example, if this could be used to access measurements of fine grained timing of the timing differences between a succession of failed session setup attempts that could in principle expose key material or plaintext. I think the right wording to add should be easy to arrive at based on a bit of discussion but will be to the effect of noting the vulnerability and saying something like "if there's crypto involved, don't do this thousands of times in the face of errors without raising an alarm" or some such. Or, perhaps you have thought about it, and this doesn't create a timing side channel vulnerability, in which case noting that would be a fine resolution of the discuss.
Only editorial comments. Please expand: SDES packets RTCP SR packets QoE
A multimedia session comprises a set of concurrent RTP sessions among a common group of participants, using one RTP session for each media type. Thank you for using "comprises" correctly! I really appreciate that.
Section 7.1.1. doesn't seem like it says what it means; it seems like a network map contains multiple PIDs. Section 7.1.1 would be more helpful if it said explicitly that the "pid" attribute is the PID for the endpoint in question.
Thanks for sorting my discuss points. I'm not that keen on the "same trust domain" term in 12.3 to be honest. That is not something a client programmer can check, and is also pretty weasel-wordy. I'd suggest changing that to saying "deployed by the same entity" or something. ---- OLD COMMENTS BELOW, not sure if they've been handled. - 2.2: How is a phone number an endpoint address? Its not really that good an idea to have not entirely obvious jokes. - 3.2: I'm surprised that expiry isn't specified, or do you mean ALTO depends on HTTP cache controls alone? (For signatures, I can buy you want to wait for JOSE.) - 8.3.7 is puzzling, is it a corollary that an ALTO server MUST NOT set cookies? Good if so, maybe make that explicit though? - 12.3 - I agree with Joel's discuss. - 15 - all environments and use-cases require consideration about attacks, its just easier for some.
The discussion about the Gen-ART review identified US-ASCII vs. UTF-8 string as a potential issue, and I agree. I can see that there was agreement on e-mail that a change shall be made. Expecting a new version to make the change.
I'd like to hear your response to Barry on his worry about a conflict between 1.1 and 8.3.2. I don't really see the conflict; just because a client can ask particular questions and get particular answers, or that some of the data in the answers is dynamic, doesn't make the information any less "published". I might agree that "unidirectional" is a strange term to use, but it is certainly "read-only". Throughout the document: I'm not a big fan of the "we" language. I think it makes it sounds like an academic paper rather than a protocol spec. I prefer "this document" or "this protocol". 6.1.2: An ALTO Client SHOULD be cognizant of operations when a desired Cost Mode is not supported. I don't know what an implementer is supposed to do with that sentence. There's nothing actionable there. What I think you mean is, "An ALTO Client MUST be able to support either mode." If that's not what you mean, then I don't know what is intended here. 188.8.131.52: It is important to note that the values in the Cost Map provided with the ordinal Cost Mode are not necessarily the actual costs known to the ALTO Server. I ask this seriously: Why is it important to note that? And who exactly should note that? Are you trying to tell server implementers that they MAY produce values in the Cost Map based on things other than their internal cost metrics? Or are you telling client implementers that the Cost Map may not be completely representational of...something? I don't know what that sentence means or what it's import is. 8.3.3: ...the ALTO Server MAY provide...or return an ALTO error object... That's a strange use of MAY. Giving the answer or giving an error don't seem like "options" in the traditional sense. I'd just say, "...the ALTO Server either provides...or returns an ALTO error object..." 8.3.6: s/MAY/can There's no protocol option being described here. 10.1 (and elsewhere in the document): If you want to be precise, you might change "alphanumeric characters" to "US-ASCII alphanumeric characters". 10.3: I don't think "and 'tag' is a case-sensitive string" adds anything, and in fact it might be confusing. You don't talk about case-sensitivity anywhere in the document, and the below paragraph already talks about "byte-for-byte equal". How about simply, "and tag is is an identifier string, as described in section 6.3". 11.5.1: "It is important to note..." It seems to me that this paragraph is simply saying, "How an ALTO Server calculates costs between individual endpoints is implementation dependent. For example, an ALTO Server could simply use the cost between the PIDs corresponding to the endpoints." I suggest that replacement.
From Jürgen, part of his OPS DIR review: I enjoyed reading a very clear and well written document. As usual, I appreciate the "Manageability Considerations" section, which provides useful guidance. For the monitoring part (16.1.4.), the document refers to [I-D.ietf-alto-deployments]. While this I-D provides more discussion, it still leaves it somewhat open how to effectively monitor the impact ALTO has on the traffic. It seems difficult to me, within an ISP network, to separate flows that are influences by an ALTO server from other flows. The assumption that ALTO-enabled applications provide that information back to an ISP running ALTO servers sounds a bit idealistic to me. I also believe it is useful to distinguish 'measurement' from 'monitoring'. One likes to measure the impact an ALTO server has on the traffic mix and one monitors the ALTO servers whether they provides say function properly and achieve acceptable response times. Section 16.2.3. says "Monitoring ALTO Servers and Clients is described in [I-D.ietf-alto-deployments]". Appendix A of this I-D talks about monitoring (actually measuring) the effects of ALTO, but it does not really talk about monitoring of ALTO servers or clients (e.g., is my ALTO server getting overloaded?). Yes, some of this overlaps with 16.2.5 - perhaps provide a pointer. Overall, I once again like to thank the authors for a very well written document. Editorial nits: - p12: s/a defined groupings/defined groupings/ - p24: s/InforResourceDirectory/InfoResourceDirectory/ - p27: s/a the Retry-After/the Retry-After/ - p81: s/from a ALTO/from ALTO/ - p81: "The following is a list of suggested ALTO-specific to be monitored [...]" Missing noun? - p86: s/are the rule/are the rules/
Nothing blocking here, just comments... but please consider them, and I'd appreciate a chat about the last one. -- Section 1.1 -- At a high level, the ALTO Protocol specified in this document is a unidirectional interface that allows a network to publish its network information such as network locations, costs between them at configurable granularities, and endhost properties to network applications. The information published by the ALTO Protocol should benefit both the network and the applications (i.e., the consumers of the information). Either the operator of the network or a third- party (e.g., an information aggregator) can retrieve or derive related information of the network and publish it using the ALTO Protocol. When a network provides information through the ALTO Protocol, we say that the network provides the ALTO Service. But in Section 8.3.2, we have this: Where possible, the ALTO Protocol uses the HTTP GET method to request resources. However, some ALTO services provide Information Resources that are the function of one or more input parameters. Input parameters are encoded in the HTTP request's entity body, and the ALTO Client MUST use the HTTP POST method to send the parameters. That says to me that this isn't unidirectional, and that it's not a question of "publishing" network information. The client is actively querying, asking for specific information, sometimes using input parameters to pass query information to the server... and the server is responding to a specific query, not publishing common information -- the response will be different for different queries, and perhaps for the same query sent by different clients. If I'm right, that's very different from publishing information, and it has very different security, privacy, and integrity properties. A lot of information can be gleaned from specific queries a client might make and parameters it might use, especially when information is aggregated from many queries over time. You do talk about risks to the client in Section 15.4.1, so I think the only issue here is that Section 1.1 is misleading. Perhaps a bit of rephrasing will help? -- Section 10.6 -- Identifiers prefixed with 'priv:' are reserved for Private Use [RFC5226]. Identifiers prefixed with 'exp:' are reserved for Experimental use. For an identifier with the 'priv:' or 'exp:' prefix, an additional string (e.g., company identifier or random string) MUST follow to reduce potential collisions. For example, a short string after 'exp:' to indicate the starting time of a specific experiment is recommended. All other identifiers that appear in an HTTP request or response with an 'application/alto-*' media type and indicate Cost Metrics MUST be registered in the ALTO Cost Metrics registry Section 14.2. These aren't really "reserved"; the idea is that anyone can freely use such identifiers without worrying about registration? This needs to be clear both to IANA and to implementors. I'm also not sure how to interpret the "MUST" here. The example gives a good clue, but... suppose Apple wants to use a private identifier. Should that be "priv:apple:myid", "priv:apple-myid", "priv:apple_myid", "priv:applemyid", any of the above? All "an additional string MUST follow" tells me is that I can't just use "priv:"... but "priv:x" would satisfy the MUST. Is that sufficiently specified for you? Similar comment for 10.8.2. -- Section 14.2 -- Identifiers prefixed with 'priv:' are reserved for Private Use. Identifiers prefixed with 'exp:' are reserved for Experimental use. Related to the comment above, this should refer to Section 10.6 for more information. You have a reference to 10.6 right before this, but I don't think it's enough to draw the eye there for this. Maybe, "As specified in Section 10.6, indentifiers prefixed with 'priv:' are for Private Use, and identifiers prefixed with 'exp:' are for Experimental use." -- Section 14.3 -- The maintenance of this registry is similar to that of the preceding ALTO Cost Metrics. I'd feel lots better if you explicitly pointed to Section 10.8.2 here. Maybe, "The maintenance of this registry is similar to that of the preceding ALTO Cost Metrics, subject to the description in Section 10.8.2." -- Sections 14.2, 14.3, 14.4, 14.5 -- All the new registries use IETF Review as their policy. They do give a reason for that (thanks!), and I accept that reason. I just have one question: is there really no desire for a provision for other SDOs, such as W3C, to create new entries? Is the desire really for them to go through the IETF in the event that they want to do that? You're probably fine here, but because this sort of requirement often paints us into a corner, I wanted to double check (or triple, or...).
"The maintenance of this registry is similar to that of the preceding ALTO Cost Metrics." You should be guided by IANA, but I think it would be better to explicitly state the registration policy.
was discuss I can live with the proposed text that came out of the discussion. in any event I said I would do this. formerly: so I raised this issue during the LC, and I'm I'm pretty sure I will clear without changes but I wanted to discuss it. section 12.3 has some pretty dire consequences in terms of the potential for abuse on the form of inadvertent disclosure or malicious (from the vantage point of the client) traffic engineering. while the document deals with those why/recommend/include it at all? The only cases where I would consider it appropriate are where the alto server and either the client or server endpoints are under a single administrative span of control.
This human in the loop says ok:-)
I have yet to do my own review of this document, but I note that during the discussion of Martin Vigoureux's Routing Directorate review, Martin suggested changes to the text in the Abstract and introduction. I have seen no follow-up on these suggestions and the text doesn't appear to have been changed. === Fernando, thanks for following up. Your explanations clarify a lot, so I think these clarifications need to be brought to the draft. You are free not to take the suggested text as is, but I think you need to keep the objective. I would start by clarifying the Abstract: OLD: That is, traffic meant to be transferred over a VPN connection may leak out of such connection and be transferred in the clear from the local network to the final destination. NEW: That is, traffic meant to be transferred over a VPN connection may leak out of such connection and be sent in the clear on the local network towards the final destination. OLD: This document discusses some scenarios in which such VPN leakages may occur, either as a side effect of enabling IPv6 on a local network, or as a result of a deliberate attack from a local attacker. NEW: This document discusses some scenarios in which such VPN leakages may occur as a result of employing IPv6-unaware VPN software. Then I believe you need to rework the first paragraph of the Introduction to clearly and rapidly state your problem space rather than loosing the reader in the VPN-to-corporate-resources sink. This echoes the comment you also received from Lee and the original one from KK. OLD: It is a very common practice for employees working at remote locations to establish a VPN connection with their office or home office. This is typically done to gain access to some resources only available within the company's network, but also to secure the host's traffic against attackers that might be connected to the same remote location. The same is true for mobile nodes that establish VPN connections to secure their traffic while they roam from one network to another. In some scenarios, it is even assumed that employing a VPN connection makes the use of insecure protocols (e.g. that transfer sensitive information in the clear) acceptable, as the VPN provides security services (such as data integrity and/or confidentiality) for all communications made over the VPN. NEW: It is a very common practice for users of a VPN software to establish a VPN connection towards a targeted endpoint when their terminal, which hosts the VPN software, is itself connected to a local network (e.g., a conference network). This is typically done to gain access to some resources which are otherwise not accessible, but also to secure the terminal's traffic through the local network (e.g., against attackers that might be connected to the same local network). The latter case constitute the problem space of this document. Indeed, it is sometimes assumed that employing a VPN connection makes the use of insecure protocols (e.g., that transfer sensitive information in the clear) acceptable, as a VPN provides security services (such as data integrity and/or confidentiality) for all communications made over that VPN. However, this document illustrates that under certain circumstances, some traffic might not be mapped onto the VPN and thus be sent in the clear on the local network.
- section 2: The terminology section is not very clear as to how TLS-based tunnels are not the same as TLS VPN portals. And the slides referenced don't really seem to cover TLS tunnels for general IP traffic but rather TLS tunnels from a browser to an entreprise, presumably with the tunnelled traffic being HTTP/XHR. I think some additional wording should clear this up. I saw that this was discussed as part of the secdir review but I don't think the text is quite there yet. Maybe, saying "IPsec VPNs and VPNs that use TLS for key manamgent, but that also tunnel general IP" is a way to cover both IPsec and e.g. OpenVPN? - section 3: routing also "ties together" different versions of IP, re-phrasing that might be better. - section 4: the "underlying problem" is that the VPN s/w doesn't support v6, not that DNS has both A and AAAA RRs. - (niggly nit) Another "turn off v6" recommendation! (sigh) - Don't VPNs also "leak" other traffic, e.g. DHCP when the non-VPN lease needs renewing or already opened connections? And if a VPN client is badly configured then lots more could leak too. Why not note these?
I'd like to see a new version with the edit that Russ Housley suggested in his Gen-ART review.
The scenarios and the solutions in this document strike me as somewhat bogus, and I'd like to hear if the WG had any data on these usage scenarios: - Most VPN installations I know of secure traffic to particular addresses by employing the VPN to do two things: a) Encrypt the traffic, and b) Get through a firewall that prevents traffic not coming through the VPN to never get to the hosts. In that case, if a non-v6 supporting VPN is used, the v6 traffic never even begins, because the traffic simply can't reach the v6 endpoints behind the firewall. Are most VPNs not employed in the way that I describe? - The document seems to assume that VPNs are somehow used to generically encrypt traffic that is not encrypted. But the vulnerability here seems to be the use of the VPN for such purposes. To secure traffic to a service, what you want to do is have the application secure the stream of data in some way (e.g., TLS), not have applications that blindly send clear traffic and then hope it goes through the VPN. Are VPNs actually being used to do this generic blind encryption? Are most of the instances of this not also instances of the firewalled scenario I asked about above? - The document refers to v4 and v6 being "'tied' together by the DNS". However, most VPNs I am aware of actually force the use of a particular DNS server on the user of the VPN. In those cases, if the VPN is v4 only, and that DNS is returning v6 addresses, it seems like the appropriate mitigation is to stop returning v6 addresses through that VPN-configured DNS server, not to disable all v6 interfaces. Are most VPNs not using their own configured DNS? - The mitigations in 7.1 never say, "Fix the VPN software to support v6", nor does it say, "stop advertising v6 addresses for things that you expect to go through the VPN". Those seems like much more sensible mitigations. The choices in the document are "use v6-enabled VPNs" or "don't use v6". Those seem like lousy choices. The analysis in this document seems very weak to me. I'm not a security guy, but the scenarios and mitigations described in this document don't seem truly representative of VPN usage. At the very least, the document never gives any data indicating that the scenarios are the real problem.
-- Section 2 -- When employing the term VPN (or its acronym, "VPN") Eh? I guess the first was meant to be spelt out.
I found this document to be pretty clear for the non-expert reader. I did have a couple of comments that you might want to consider, along with any other comments you receive. In this text: 7.1. Fixing VPN client software Finally, we note that if (eventually) IPv6-only VPN implementations become available, they should consider similar issues that would ^^^^ arise if they do nothing about the IPv4 traffic. ^^^^ I'm reading "they" as "IPv6-only VPN implementations", but I'm not sure that's what you intended. I might also have guessed "administrators", if I was guessing. If you meant something else, could you consider using a noun, and not a pronoun? In this text: 9. Security Considerations Possible ways to mitigate this problem include fixing the VPN client software, or disabling IPv6 connectivity on all network interfaces when the previous option is not feasible. These are the recommendations the document is making, are they not? I would have thought what this section is asking for, is what security considerations might arise from following those recommendations. Finally, Stephen was asking about what else might leak, which is an interesting question, but I'm wondering if that's something different - he's talking about "leaking" (say) a small amount of DHCP traffic that someone could eavesdrop and learn something the eavesdropper shouldn't know, while IIUC, this draft is mostly about 'leaking" potentially a much larger and potentially more revealing amount of traffic (like, all of the email I'm downloading from my mail server), and (in these two examples) potentially "leaking" it over a much larger distance (network-wise). Is there a better term for what this document is describing? "No", or "no, that's actually the right term of art on both cases", would be a fine answer ...
What Pete said... This is another example of giving guidance to disable IPv6 rather than guidance on how to address the limitations causing the perceived problem. I would have liked to have seen, for example, guidance on what DNS record types should be available via a VPN connection running over IPv4.
I found this in Section 8.3: >Editorial Comments > >[CREF1] JLS: Should this be an EAP failure to the client as well? Is this a left over or still an open question?
Some nits: 6.2. Resource Reservation Session status normally is managed by a static timer. For example, the value of the "established connection idle-timeout" for TCP sessions must not be less than 2 hours 4 minutes[RFC5382] and 5 minutes for UDP sessions[RFC4787]. This text isn't exactly clear about who is supposed to handle the timers and also the 5 minutes for UDP is not 'less than 5 minutes' but it is RECOMMENDED to be 5 minutes and 'MUST NOT expire in less than two minutes'. A text change proposal to get it correct: The session status at the NAT normally is managed by a static timer. For example, the value of the "established connection idle-timeout" for TCP sessions must not be less than 2 hours 4 minutes[RFC5382]. For UDP sessions the timer must not be less than 2 minutes [RFC4787], but the recommended value is 5 minutes.
A minor editorial improvement would make the draft easier to read (when looking at the HTML version, http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-09). Some references don't mention the RFC title and don't have an embedded link. I had to open a new window, and google the RFC number. Examples: - [RFC6036] reports at least 30% of operators plan to run some kind of translator (presumably NAT64/DNS64). - ... while it has to be coordinated with A+P[RFC6346] - For example, the value of the "established connection idle-timeout" for TCP sessions must not be less than 2 hours 4 minutes[RFC5382] and 5 minutes for UDP sessions[RFC4787].
Excellent document, thanks. 184.108.40.206, last para: "This document makes the following recommendations." Is some text here a cut'n'paste error? 2.6.1, I don't get "Only where hardware can identify a signature and the portion of packet covered by the signature is cryptographic authentication highly beneficial in protecting against DoS attacks." What is that meant to mean? I'm guessing signature there does not mean digital signature. 2.6.1, To be honest this section reads like there's not that much known about DoS mitigation at this layer, (or that someone's not saying:-) Either would be surprising. Is there not more to be said? (Honest question, I don't know how DoS-mitigation is done down here;-)
-- Section 1.2 -- This document is informational. The upper case [RFC2119] key words are not used in this document, except in the following cases. In fact, there's quite a lot of 2119 language in here, and this makes it sound like there isn't. I suggest re-wording this: NEW This document is informational. The upper case [RFC2119] key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are used in this document in the following cases. END
This document is a real treasure. Thank you for producing it.
This is a well written document. However I do have some comments that I would ask the authors to consider: In 2.1.7. MPLS Fast Reroute (FRR), there should be some discussion of RFC5286, and possibly RFC5714 and draft-ietf-rtgwg-remote-lfa since they are all deployed in MPLS networks. ===== 1. Introduction and Document Scope The initial purpose of this document was to address concerns raised on the MPLS WG mailing list about shortcomings in implementations of MPLS forwarding. SB> "The initial purpose" implies a later purpose, but that is not clear. ===== SB> It would be useful to warn the reader of the issues with non-IETF definitions of MPLS. For example the G8110 the definition of MPLS led to incorrect assumptions which were noted in RFC5704 ==== 2.1.3. Time Synchronization "PTP and NTP timestamp formats differ slightly. " SB> The difference is surely fundamental! ==== PW services which are not timing critical bit streams in nature are cell oriented or frame oriented. SB> Actually some ATM cell streams are also timing critical ==== 2.3. Packet Rates Internet service providers and content providers at one time specified full rate forwarding with 40 byte payload packets as a requirement. Today, this requirement often can be waived if the provider can be convinced that when long sequence of short packets occur no packets will be dropped. SB> Doesn't this then feed the buffer bloat problem? ==== Appendix A. Organization of References Section This would be more useful as section 8.0 ==== You might want to give a heads up to the work on SPRING which will further inflate the label stack. ==== It might be useful to add some text on IPFIX in particular IEs 46,47, 70..79, 90, 91, 140, 194
- I like the document overall, thanks! - It'd be an easier read if references were given more readable names, e.g. things like "Some have therefore proposed weakening the security constraints of ..." make it hard to know what's meant sometimes. I get that this'd be a lot of editing work to fix though, but I think it would make the eventual RFC more useful for longer if someone has the time and energy. - 5.3 uses the term "nonce" wrong I think, I guess you mean cookie really. - 6.2, a reference for the "some national authorities" statement would be nice to have. - 6.3, "architecting new certificate authorities" isn't quite right, you're talking about building new PKIs which is a deployment and not necessarily a s/w thing. Bit of a nit though. - 6.X, I could suggest adding a new 6.7 since another important thing that has changed is snowdonia. I can buy that that's not done here though since STIR has been underway whilst we're still figuring out snowdonia. It could still be worth noting though, since there is a real tension there the WG will have to deal with. That tension being the inherent one between securing origin information (good) and assisting pervasive monitoring (bad). I realise that not all those involved in STIR do consider PM as a bad thing, as least insofar as it might be assisted by STIR, but nonetheless the tension is real. - 7: I think you should say that these requirements will be elucidated further in the WG. The reason is that they're quite informally stated (e.g. "golden root") which is ok as long as they're not used later as gospel since that would likely lead to repeating arguments and delay. If you do mean these requirements as gospel, then I think I'd likely turn this into a discuss. - 7: The privacy requirement is limited to the out-of-band case. I'm sure there will be things to say about the in-band case too that will be different for different potential solutions. I'm not sure if there's a useful requirement you can state here though for that without getting into solution detail. Was that considered?
What is not clear to me: is this document supposed to contain requirements, or is this supposed in https://datatracker.ietf.org/doc/draft-ietf-stir-threats/ ? Or maybe the two? The charter is not too clear about this. I'm mean: certainly, we would have some (others) requirements from the threat model, right? However, I don't even see the "requirement" word in draft-ietf-stir-threats? Can you please clarify Unlike some of my esteemed IESG colleagues, I actually like this document, which gives some history, explain the problem statement, and explain the limitations of the current solutions. Granted, it's a little bit verbose, but if one document type could be verbose, this would be problem statement. On regular basis, I claim that the IETF makes it too difficult for for newcomers to jump on the IETF train (how many SIP RFCs do we have?). This type of document provides the needed entry point. I agree with Spencer's and Stephen's comments.
Indeed, what Brian said. I think it's important for us to take a step back and pare down some of the language we put into documents that amounts more to marketing hype than to technical material. My sense is that most people reading this would glaze over before they got to the important bits.
This first comment is about halfway to a Discuss. If the IESG wasn't already chatting about application of the Discuss criteria to a ballot for another document and frightening the incoming ADs, and if this wasn't pretty obviously a problem and trivial to fix, I'd have balloted Discuss, so please fix it :D This document contains a problem statement *and* requirements resulting from that problem statement, but the presence of a section on requirements isn't apparent from the document title, and isn't mentioned in the Abstract. There's one mention of requirements (and maybe even "start of an attempt to develop requirements") several paragraphs into the Introduction: With this document we would like to start an attempt to develop a common understanding of the problem statement as well as requirements to develop a vision on how to ^^^^^^^^^^^^^^^^^^^^^^^ advance the state of the art and to initiate technical work to enable secure call origin identification. and nothing else until you hit 7. Requirements This section describes the high level requirements of the effort: If you could make the requirements a bit more visible, that would be great. As it is, if someone asked me where the requirements for STIR are after this doc is published, I couldn't find them from the RFC index or from the abstract. The rest of these comments are mostly places where the document wasn't clear to me, or was more US-centric than I was comfortable with. Please consider them along with any other comments you receive. In this text: 1. Introduction With this document we would like to start an attempt to develop a common understanding of the problem ^^^^^^^^^^^^^^^^ statement as well as requirements to develop a vision on how to advance the state of the art and to initiate technical work to enable secure call origin identification. I'm not understanding what "start an attempt" means - is the intention that a follow-on problem statement doc would be published later? I would have guessed "yes" from this, but then I guessed "no" because the document also contains requirements, and now I'm back to being lost. In this text: 2. Problem Statement This model worked as long as the number of entities was relatively small, easily identified (e.g., through the concept of certificated ^^^^^^^^^^^^ carriers) and subject to effective legal sanctions in case of misbehavior. does "certificated" have a different meaning than "certified"? It's a word (I checked), but it's not a familiar word to me. In the same section: Other boiler-room ^^^^^^^^^^^ is this word clear to non-native English speakers? organizations use number spoofing to place illegal "robocalls" (automated telemarketing, see, for example, the FCC webpage  on ^^^ please expand, and qualify as "US"? this topic). Robocalls are a problem that has been recognized already by various regulators; for example, the Federal Trade Commission (FTC) recently organized a robocall competition to solicit ^^^ please qualify as "US"? ideas for creating solutions that will block illegal robocalls . In this text, but not only in this text: 4.4. VoIP-to-PSTN Call Consider Figure 4 where Alice calls Carl. Carl uses a PSTN phone and Alice an IP-based phone. When Alice initiates the call the E.164 number needs to get translated to a SIP URI and subsequently to an IP ^^^^^^^^^^^^ is? address. The call of Alice traverses her VoIP provider where the call origin identification information is added. It then hits the reaches? ^^^ PSTN/VoIP gateway. the wording is more casual than I'm accustomed to (and I'm a pretty casual guy). If someone could make a gentle pass looking for wording like this, that would be helpful for ESL readers. In this text: 5. Limitations of Current Solutions SIP Identity is meant both to prevent originating calls with spoofed From headers and intermediaries, such as SIP proxies, from launching man-in-the-middle attacks to alter calls passing through. the wording was difficult for me to grok. Does that mean something like this? SIP Identity is meant to prevent SIP UAs from originating calls with spoofed From headers and to prevent intermediaries, such as SIP proxies, from launching man-in-the-middle attacks by inserting spoofed headers as calls pass through. In this text: 7. Requirements Usability: Any validation mechanism must work without human intervention, e.g., CAPTCHA-like mechanisms. ^^^^ I know what you mean, but the text says (in Latin) "for example, CAPTCHA", and I'm pretty sure you mean "anything but CAPTCHA". In this text: 10. Security Considerations This document is about improving the security of call origin identification. Right. There will be security considerations associated with that improvement. I think it's fair to say they'll be addressed in the documents that define those improvements, but this is kind of a punt.
I don't have an issue with the general premise of this document. However, I think its verbosity leads to significant information loss, resulting in a far less useful document. For example: 1. It is completely unclear that there will be a list of requirements at the end of the story (hence part of Spencer's Comment). 2. The actual problem statement section contains far more historical context than actual statement of a problem. 3. Sections 4.x could easily be condensed into a concise (and readable) bulleted list. 4. Sections 5.x do not need long-winded descriptions of the current solutions. A reference will do. I think the document would be much more useful in a condensed format. However, since the WG has consensus on this formulation, I am not going to stand in the way.
How is the IMEI URN validated when presented? I suspect that one of the RFC references says, but if so you should indicate that this question will be answered by reading the referenced RFC.
The RFC editor will want you to remove citations and RFC 2119 language from the Abstract. You might do that if you have to respin the document for any reason.
I do think this draft is trying to say all the right things, but there are a few discuss points I'd like to chat about. Some related to wording and some where I may be just confused (which happens easily:-) (1) (This is the same as a discuss point for the other GSMA doc and can be resolved identically.) "loosely correlated to a user" seems like its trying to hide that IMEIs are PII. And "messages intended to convey any level on anonymity" is not meaningful - what does that really mean when you look at it? (I suspect that might just be unfortunate phrasing from IETF LC discussion.) I suggest you simply state that "almost all IMEIs are almost always PII and so these URNs MUST be treated as PII in all cases." (2) Section 5 is the key for me here saying that a UAC ought only send this when registering with a 3gpp ims n/w. How does a UAC know when that is happening, vs. when the UAC is registering with some other n/w? Are there any weird b2bua cases here btw? (3) Should you state somewhere that a UAS (or maybe others too) SHOULD NOT log the instance ID, or if they do, that they need to protect that as PII? I'm not sure if sip.instance is normally logged nor how such log entries are usually treated. (4) Other than TLS, what security mechanism can really be used for protecting these instance IDs? If there is none (that is credible), then wouldn't it be better to leave out the "or" bit since that way the UAC can enforce TLS, whereas as is you are forcing the UAC to have a non-TLS option which is probably what'll always get used and maybe will be all that's implemented? (Is that fair? If not, apologies:-)
- s5, 2nd para: "A UAC MUST only..." would maybe be better stated using "MUST NOT... when its not a 3gpp ims n/w"? - s7: ref  in .doc form crashes libreoffice on me which is a pity:-( In any case, I think that the "obfuscation" is just a call to sha-1, is that right? I think I'd like if it were better but I guess there's nothing practical that can be done about that now, is that correct?
- To be honest, I'm not clear why this was needed really but I guess it was part of some NIST test suite work and its fine to record that. Anyway, once the OIDs are assigned for this, then recording it is correct. - I'd suggest s/has a/can have a/ in the 2nd sentence in section 3. - section 4: are these OIDs going to be part of the new PKIX IANA OID registries? I assume so and they'll be registered for that via some other document? Would it be nice to also name that IANA registry here though? (At the expense of holding this up until that is done.)
From the Gen-ART review by Francis Dupont: - typo 3 page 2: ... The actual polices used for production certificates has a significant impact ^ BTW if the word is policies than has -> have
It's a bit weird to hard-code a contact person into an RFC: Designated contact person: Name: Paul Gosden Coordinates: firstname.lastname@example.org Wouldn't it make more sense to have a role address @gsma.com and give the role a name, like "Designated GSMA Contact Person For IMEI/IMEISV URN Registries"? imei-specifier = "imei:" ( imeival / ext-imei ) [ ";" sw-version-param ] [ ";" imei-version-param ] Are sw-version-param and imei-version-param actually relevant for ext-imei?
I do recall but didn't have a chance to review the IETF LC discussion of this so feel free to point me at relevant bits of that. FWIW, I appreciate that the authors were responsive to the privacy issues raised in that discussion, but I also think there's maybe a bit more work to be done. (1) I accept that there are valid uses for these URNs at least within mobile operator networks, but, like others, am concerned that we're defining a pretty invasive form of PII that can be perhaps too easily dropped into protocols that don't properly protect such information or that are typically not deployed with such protection enabled. I'm not sure how best to address this in general and would like to discuss that with the IESG and authors in general as well as the more specific discuss points below. (2) I think the abstract should have a brief mention of the privacy issue, e.g. something like "URNs from this namespace almost always contain Personally Identifying Information and need to be treated accordingly." If doing this, then a slightly longer paragraph along the same lines in the intro would probably also make sense. (3) Given that IMEIs are PII, and that devices may then emit those, would there not be value in defining an "I'm not telling" URN value that could be used by devices (whose users) would (sometimes) prefer privacy over convienence? As-is, when a protocol uses one of these URNs, then the only option is to not run the protocol or to expose the PII. Wouldn't the existence of such a URN value help there, e.g. perhaps "urn:gsma:imei:anon" or it could of course use the existing syntax but just some numbers never allocated to a real device as an IMEI, and I'm sure there are such values that could be added here as a special case. (4) "care SHOULD be taken" seems meaningless to me and "MUST NOT be delivered to devices that are not trusted" is definitely meaningless in my universe (though perhaps it seems less so in GSM). I think you need to say when these URNs can be safely used, and then say that other uses are NOT RECOMMENDED. Is there a way to characterise that crisply? If there's not, then how is this safe really? (5) "loosely correlated to a user" seems like its trying to hide that IMEIs are PII. And "messages intended to convey any level on anonymity" is not meaningful - what does that really mean when you look at it? (I suspect that might just be unfortunate phrasing from IETF LC discussion.) I suggest you simply state that "almost all IMEIs are almost always PII and so these URNs MUST be treated as PII in all cases." (6) I personally think you should state that protocols carrying these URNs MUST or SHOULD do so over strongly hop-by-hop encrypted channels at least, and ideally encrypted end-to-end. I can imagine that might not fit with some real planned uses though, but I'd like to discuss it a bit to see. The "if sent in clear" paragraph is just too weak I think.
- On Barry's discuss. I think there would be value in IETF review if e.g. the GSMA wanted to define other urn:gsma: namespaces that were likely to contain PII, for example a putative urn:gsma:imsi perhaps. Given the cross-over nature of these kinds of identifier, I think such review would be valuable. - Section 5: I'm not gettng the intent of this section. Can you explain why its there? - Section 8: This would be better named "Security and Privacy Considerations" for this document I think. - Section 8, para 1: suggest s/proof/"proof"/ in the 2nd last sentence - scare quotes seem appropriate there:-) - S8, 2nd para: The IMEI and s/w version definitely will identify the set of known vulnerabilities (whether zero day or not). Saying that's a "possibility" is a significant understatement.
I agree with Barry that the IETF probably doesn't need control over the internals of the namespace.
This document's been around for a long time, and we should get it through already. That said, there's an issue I want to talk about: -- Section 3 -- future-specifier = gsma-defined-nonempty ;GSMA defined and ;IETF consensus ;required ... Additional NSS may be added for future identifiers needed by the GSMA using the procedure for URN NSS changes and additions (currently through the publication of future Informational RFCs approved by IETF consensus). Having registered your "gsma" namespace and defined a "urn:gsma:imei:" sub-namespace, do you really want to require IETF consensus to create other sub-namespaces under "urn:gsma:"? That seems odd. I should think you'd want to have the authority to register things under "urn:gsma:" go to some GSMA management entity instead of to the IETF. If you really want to have it be through IETF consensus, I'll clear my DISCUSS forthwith. But let's please talk about what the right path here is.
Two other, non-blocking points: 1. There are two unused normative references,  (UTF-8) and  URN syntax. They should be anchored. I gather that  was put in to resolve Magnus's DISCUSS from 2009, but it's not sufficient just to stick in a reference -- the appropriate spot in the text needs to refer to it. 2. A very, very minor suggestion: This sentence is at a level of detail that's out of place in the Abstract, and I suggest removing it: The IMEI is 15 decimal digits long and the IMEISV is 16 decimal digits long and both are encoded using Binary Encoded Decimal (BCD). That information is correctly provided in the Introduction.
I re-iterate the position of my ancestors.
The security considerations could mention that including this might help bind the email From and JID for surveillance purposes as well as for spam. I'd argue that the 2nd "ought" is too weak: s/ought/need to/ would be better IMO. (And in case I got the count wrong, I mean the one where you say a UA "ought" allow the user to stop sending this.)
I can never remember whether I should recuse or not when a document from the RG I co-chair comes up. This time, I'll recuse:-)