IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2014-08-07. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Russ, Barry, Amy
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
1211 EDT 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. Agenda Working Group News
Amy: I will not be here in two weeks; Cindy will handle; please discuss how you want to invite the world, we have no procedures yet
1237 EDT Adjourned
(at 2014-08-07 07:30:00 PDT)
I'm probably missing something here, so please help me out. The text in 4.2 says: It is possible that the MPLS Echo Request packet was intercepted before the intended destination for reason other than label TTL expiry. This could be due network faults, misconfiguration or other reasons. In such cases, if the return TTL is set to the value specified in the TTL TLV then the echo response packet will continue beyond the originating node. This becomes a security issue. To prevent this, the label TTL value used in the MPLS Echo Reply packet MUST be modified by deducting the incoming label TTL on the received packet from TTL TLV value. If the MPLS Echo Request packet is punted to the CPU before the incoming label TTL is deducted, then another 1 MUST be deducted. In other words: Return TTL Value on the MPLS Echo Reply packet = (TTL TLV Value)- (Incoming Label TTL) + 1 The second paragraph concludes by saying "another 1 must be deducted," but the math in the third paragraph appears to be adding one, possibly because not enough parentheses were used. What was intended here?
I also agree with Barry's discuss.
In section 3.1, do you want to put in the usual "Reserved - MUST be zero (MBZ) when sending and ignored on receipt."? Barry's covered the rest.
This document got on the agenda on August 4th, for the August 7th meeting. I got a complaint from the Secdir secretary that it is too short time for them to do their usual re-review for the telechat. He believes there is no issue in this document, but can we avoid this situation in the future?
I find Section 3.2 sufficiently confusingly worded and unclear that I think we need to have a discussion about re-wording it. I offer suggested re-wording below, but please bear with my thought process on the way there: This TLV SHALL be included in the MPLS Echo Request by the originator of request. The use of this TLV is optional. That "SHALL" conflicts with the second sentence. My sense is that it's not really a MUST. Perhaps you mean "MAY be included"? In which case, you don't need the second sentence at all, because that's what "MAY" says. (Type value of TLV is assumed to be in the range of optional TLV's which SHOULD be ignored if an implementation does not support or understand them) "Assumed to be"? Shouldn't this simply be "is"? If a receiver understands the TTL TLV, and the TTL TLV is present in the MPLS Echo Request, the receiver MUST use the TTL value specified in TLV in the MPLS header of the MPLS Echo Reply. In other words, if the value of the TTL provided by this TLV does not match the TTL determined by other means, such as Switching Point TLV in MS-PW, then TTL TLV MUST be used. This will aid the originator of the LSP-Ping echo request in analyzing the return path. I find this to be impossibly confusing in its wording, and I had to read it several times before I thought I understood what you're trying to say. Whenever you need to put in "in other words," you should consider that a clue that re-wording would help. As I find the whole section to be awkward, and as the section isn't long, may I presume to suggest re-wording for the section? Of course, please correct any inaccuracies I might have introduced here... but please do consider a re-wording such as this. NEW 3.2. Usage The TTL TLV MAY be included in the MPLS Echo Request by the originator of the request. If the TTL TLV is present and the receiver does not understand TTL TLVs, it will simply ignore the TLV, as is the case for all optional TLVs. If the TTL TLV is not present or is not processed by the receiver, any determination of the TTL value used in the MPLS label on the LSP-Ping echo reply is beyond the scope of this document. If the TTL TLV is present and the receiver understands TTL TLVs, one of the following two conditions apply: o If the TTL TLV value field is zero, the LSP-Ping echo request packet SHOULD be dropped. o Otherwise, the receiver MUST use the TTL value specified in the TTL TLV when it creates the MPLS header of the MPLS Echo Reply. The TTL value in the TTL TLV takes precedence over any TTL value determined by other means, such as from the Switching Point TLV in the MS-PW. This precedence will aid the originator of the LSP-Ping echo request in analyzing the return path. END
-- Section 1 -- But, if the originator is not at the end of the MS-PW, the receiver of the MPLS Echo Request MAY need to know how many hops away the originator Tiny point: this is not a 2119 "MAY", so it shouldn't be in all caps. If you want to indicate stress, please use "*may*" or "_may_", though you can probably skip that and just make it "may". -- Section 4 -- D detects the TTL TLV in the request, and use the TTL value (i.e., 2) specified in the TLV on the MPLS label of the MPLS Echo Reply. This has a similar problem to part of what confused me in Section 3.2. It looks like you mean it to be parsed this way: "...and use (the TTL value (2) that is specified in the TLV on the MPLS label of the MPLS Echo Reply) [for what?]." But I think you actually mean it to be parsed this way: "...and use (the TTL value (2) that is specified [in the Echo Request]) and put it into the TLV on the MPLS label of the MPLS Echo Reply." Am I correct here? If so, then wording it that way would be *much* clearer: NEW D detects the TTL TLV in the request, and uses that TTL value (2) to put into the TLV on the MPLS label of the MPLS Echo Reply. END The same operation will apply in the case a co-routed bidirectional LSP and we want to check connectivity from an intermediate LSR B to another LSR D, from B. I can't parse this. I think you mean this: NEW The same operation will apply when we have a co-routed bidirectional LSP, and we want to check connectivity from an intermediate LSR "B" to another LSR "D". END -- Section 4.1 -- In the traceroute mode TTL value in the TLV is successively set to 1, 2, and so on. This is similar to the TTL values used for the label set on the packet. May I suggest this, as perhaps clearer (this one is far less important a suggestion than the earlier ones)?: NEW In traceroute mode, the TTL value in the TLV is set to 1 for the first Echo Request, then to 2 for the next, and so on. This is similar to the TTL values used for the label set on the packet. END
I support Barry's DISCUSS point on section 3.2.
IANA has reviewed section 7, so I'm marking the DISCUSS as resolved. All other comments still apply, of course. In 4.2: It is unusual to delete an existing command from an application for the sake of deleting it or the functionality it represents. This normally indicates of a flawed design. An exception might be if the intent of the deletion is to create a newer variance of the same application that is somehow simpler than the application initially specified. The second sentence seems to be making the same point as the third sentence: you are deleting a command because the original design is flawed. By stating it this way you seem to be weakening the point. Is that what was intended, or is the second sentence referring to the _new_ design? If the latter, some wordsmithing here might improve the document. In 4.3.1: o Adding one or more optional AVPs and indicating (usually within descriptive text for the command) that at least one of them has to be present in the command. This essentially circumventing the ABNF and is equivalent to adding a mandatory AVP to the command. Isn't this a MUST, not a SHOULD? In general, if the possibilities enumerated in this list are definitely going to cause interop problems, they should be MUSTs; if they are likely to cause interop problems, you should specify a test that indicates when violating the SHOULD is okay. I don't think the test will be precise, but a little bit clearer guidance might be beneficial. In 4.4.1, it might be helpful to talk about the case where a new application makes an AVP mandatory that is not mandatory in existing applications. Suppose an AVP is received without the M bit set when it's mandatory for that application. Is that an error? Should the recipient reject the communication? In 5.2: As a general recommendation, commands SHOULD not be defined from SHOULD NOT the NOT be capitalized, to be consistent with the SHOULD? :) I see that this occurs again several times in the document. Ordinarily SHOULD and NOT are capitalized consistently, whether it's "should not" or "SHOULD NOT" and not "SHOULD not." But this is a fairly minor nit. Defining a command with most of the AVPs indicated as optional MUST NOT be seen as a sub-optimal design introducing too much flexibility in the protocol. It's a little weird to use normative language to tell people how to think about something. The use of normative language in this document in general is a bit challenging, but I think appropriate because you're specifying best practices for achieving interoperability. But in this case I think you should not use normative language. I'd word it this way: Defining a command with most of the AVPs indicated as optional is good design in many cases, despite the flexibility it introduces in the protocol. Or just restate it as you did, but as a fact rather than an admonition about how to think. And then: The protocol designers SHOULD only clearly state the condition of presence of these AVPs and properly define the corresponding behaviour of the Diameter nodes when these AVPs are absent from the command. How about: Protocol designers SHOULD clearly state the reasons why these AVPs might or might not be present and properly define the corresponding behavior of the Diameter nodes when these AVPs are absent from the command. And: NOTE: As a hint for protocol designers, it is not sufficient to just look at the command's CCF syntax specification. It is also necessary to carefully read through the accompanying text in the specification. This looks like a hint for implementors, not protocol designers. I am confused. Do you mean that protocol designers should, when defining the spec, include a recommendation that implementors read the accompanying text as well as the CCF specification? In 5.5: Based on these considerations, protocol designers SHOULD carefully appraise whether the application currently defined relies on its own session management concept or whether the Session-Id defined in the Diameter base protocol would be used for correlation of messages related to the same session. If not, the protocol designers MAY decide to define application commands without the Session-Id AVP. This is stated in an overly detailed way, and "if not" is confusing, because the preceding statement contains two possibilities, neither of which is obviously negative. It's clear on reflection what is meant, but it might be better stated something like this: Based on these considerations, protocol designers SHOULD carefully consider whether the application currently defined relies on its own session management concept. If not, the protocol designers MAY decide to define application commands without the Session-Id AVP, and rely on the Session-Id defined in the Diameter base protocol for correlation of messages related to the same session. Also: If any session management concept is supported by the application, the application documentation MUST clearly specify how the session is handled between client and server (as possibly Diameter agents in the path). Was that supposed to be "and possibly" rather than "as possibly"? In 5.6: If such extension is foreseen or cannot be avoided, it is RECOMMENED to rather define AVPs of type Unsigned32 or Unsigned64 in which the data field would contain an address space representing "values" that would have the same use of Enumerated values. It is not obvious to me why this is so. It seems as if using an unsigned integer with some set of known values in application A, and then adding some new values to the same AVP in application B, is no different than defining an enumeration in application A with some set of possible values, and extending the enumeration in application B with some additional values. I am sure that there is a reason why you have made this distinction, and I could take a guess as to what the reason is, but my point is that you should really just state what the reason is clearly in this section, rather than simply stating your conclusion, because as written the section is really puzzling to me, a reader who is not steeped in the traditions of Diameter. In section 5.7: Whatever the criteria used to establish the routing path of the request, the routing of the answer MUST follow the reverse path of the request, as described in [RFC6733], with the answer being sent to the source of the received request, using transaction states and hop- by-hop identifier matching. In particular, this ensures that the Diameter Relay or Proxy agents in the request routing path will be able to release the transaction state upon receipt of the corresponding answer, avoiding unnecessary failover. Application designers SHOULD NOT modify the answer-routing principles described in [RFC6733] when defining a new application. This seems like something that could, if ignored, result in some bad behavior. It also seems like something that's not clearly enforced by a mechanism that you've pointed out here. So it would be good if the risk of abuse by clients responding to such messages could be discussed either here or in the security considerations section, and if there is some recommended mitigation strategy, that it be mentioned as well. Possibly there is no risk, but that doesn't seem likely since if that were the case, this text would seem unnecessary. Section 5.11 appears to be speaking to implementors. The advice it gives is good, but is there an expectation that implementors will read this document? In 6: In the case where the optional AVPs can be carried by any application, it SHOULD be sufficient to specify such a use case and perhaps provide specific examples of applications using them. I can't see how SHOULD could be normative here, so perhaps it shouldn't be uppercase? This is a great document. Thanks for doing it!
Please to a pass to check for unexplained abbreviations. I see: AVP EAP --- Section 9 Although such an extension may be related to a security functionality, the document does not explicitly give guidance on enhancing Diameter with respect to security. I find that disappointing. Surely there are ways to extend Diameter that would compromise security, and ways that extensions should be made in order to leverage existing security techniques. Surely there is information that could be shipped in Diameter that is confidential or private and so advice is needed about how to protect that data if an extension is made to exchange it. I'm not about to require you to write new text in this section, nor will I be suggesting text, but if you were to find the time and energy to write a few more words you would make an old AD very happy.
- Hannes' affiliation was not NSN on the date of publication. Makes one wonder if he saw this going by.
A few comments, for instance, that this document wasn't pushed through the id-nits tools which showed a number of RFC 2119 confusions, see at the end of this email. Further, what about the TBDs in Section 5.6. "Use of Enumerated Type AVPs", i.e., listed with the values 1001 and 1002? Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Additionally, application designers using Vendor-Specific-Application-Id AVP SHOULD not use the Vendor-Id AVP to further dissect or differentiate the vendor-specification Application Id. Diameter routing is not based on the Vendor-Id. As such, the Vendor-Id SHOULD not be used as an additional input for routing or delivery of messages. The Vendor-Id AVP is an informational AVP only and kept for backward compatibility reasons. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: As a general recommendation, commands SHOULD not be defined from scratch. It is instead RECOMMENDED to re-use an existing command offering similar functionality and use it as a starting point. Code re-use lead to a smaller implementation effort as well as reduce the need for testing.
Gen-ART review comments from Martin Thomson need to be acted upon; there was some discussion of them but it is not clear to me if all have been done by now. Can the authors or shepherds clarify the situation? Thanks.
I think section 4.1 could use a good edit pass. I found several of the sentences rather convoluted. The worst seemed to me: The need for a new application is due to the fact that a Diameter node not upgraded to support the new application and therefore the new command will reject any unknown command with the protocol error DIAMETER_COMMAND_UNSUPPORTED and the transaction will fail. I think you mean: A new application is required so that a Diameter node that has not been upgraded to support the new application, and therefore the new command, will reject any unknown command with the protocol error DIAMETER_COMMAND_UNSUPPORTED and the transaction will fail. There are quite a few sentences that are complicated enough to cause confusion, or at least the need to re-read multiple times. (BTW: Others have commented on fixing of some of the 2119 usage. The SHOULD in the second paragraph of 4.1 seems to be another instance.)
The draft looks very good, thanks for your work on it! I just have one suggestion: The introduction should state what Diameter is and could use a sentence or two from RFC6733, such as the first sentence in the abstract (below) put into this draft's introduction. There is no mention of what Diameter is in the draft and this would avoid confusion that there isn't another thing called diameter. The Diameter base protocol is intended to provide an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. Thanks for addressing the SecDir Review: http://www.ietf.org/mail-archive/web/secdir/current/msg04241.html
Ted gives some excellent comments; please address them. In addition: -- Section 4.3 -- Although reuse of existing commands is still RECOMMENDED, protocol designers MAY consider defining a new command when it provides a solution more suitable than the twisting of an existing command's use and applications. This is 2119 error number 1: SHOULD and MAY don't combine this way. MAY specifies that something is entirely optional, and SHOULD does not. If you want the 2119 "RECOMMENDED", I suggest you change the "MAY" to "can". -- Section 5.10 -- An application MAY define a new set of commands to carry application-specific accounting records but it is NOT RECOMMENDED to do so. There's 2119 error #1 again, this time in reverse order. If it's NOT RECOMMENDED, then it's not a "MAY". Why say that you can do it, if it has a 2119 SHOULD NOT on it? Just say, "Defining a new set of commands to carry application-specific accounting records is NOT RECOMMENDED." -- Section 7 -- The IANA AAA parameters page can be found at http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml That's not how IANA wants us to use their URIs. Please use this one instead: http://www.iana.org/assignments/aaa-parameters
Thanks for putting this document together. There are a lot of confusing uses of 2119 keywords in this document. Other ADs have commented on most of it, but there are a few instances where a requirement is put on application designers that seems like it would make more sense in lower case, e.g.: 4.3.1: Application designers SHOULD consider the following questions when deciding about the M-bit for a new AVP: (Compare with 4.1 - "application designers should consider the following:" -- why is one normative and not the other?) 5.5: Based on these considerations, protocol designers SHOULD carefully appraise whether the application currently defined relies on its own session management concept or whether the Session-Id defined in the Diameter base protocol would be used for correlation of messages related to the same session. 6: In the case where the optional AVPs can be carried by any application, it SHOULD be sufficient to specify such a use case and perhaps provide specific examples of applications using them.
7: The UAC SHOULD set the "purpose" header field parameter to "isdn-uui". Non-inclusion of the "purpose" header field parameter is permitted, but this is primarily to allow earlier implementations to support this package. It seems to me that SHOULD ought to be MAY, and you can strike the second sentence. It is already the case that draft-ietf-cuss-sip-uui defaults to isdn-uui, so there is no harm in not including it. 8: When sending UUI for the ISDN package, the UAS SHOULD set the User-to-User "purpose" header field parameter to "isdn-uui". Non-inclusion of the "purpose" header field parameter is permitted, but this is primarily to allow earlier implementations to support this package. Same comment as above.
(1) section 14 says: "As this capability is defined to interwork with the ISDN, if the ISDN forms part of the route, any usage needs to assume that the security level of the ISDN is the highest level of security available." That makes no sense to me. I think what you mean is that ISDN security isn't great so don't expect too much, and that'd be fine. However if what you mean is "ISDN security isn't great, so there's no point in doing better for SIP" then I'd disagree. I can't tell if you mean that latter thing though. (2) I expected to see some listing of known security and privacy issues with the ISDN services (or a reference to something on that). Without that, how can a SIP developer or deployer know the level of sensitivity of these headers? For example, can I only use the ISDN service or innocuous stuff or could e.g. banking PINs be included? Can you explain why its ok to not include any such discussion?
Scott Brim made the following comment in his Gen-ART review: A new sentence needs reworking: "If an interworking point is reached, and the limitations of the ISDN (see section 3.1) are not met, then the UUI data will not be transferred, although the SIP request will otherwise be interworked, rather than have the interworking point attempt to resolve the non- compliance with the limitations of ISDN." I suggest splitting it into two sentences, something like: "If an interworking point is reached, and the limitations of the ISDN (see section 3.1) are not met, then the UUI data will not be transferred, although the SIP request will otherwise be interworked. This is rather than have the interworking point attempt to resolve the non- compliance with the limitations of ISDN."
Thanks for addressing the SecDir review comments. I just have one additional comment that is non-blocking as I would not expect this draft to address security concerns, but rather just make sure it is clear they are handled elsewhere. I think the last paragraph of the Security Considerations section makes that point clear enough. I had a little trouble reading the second paragraph of the Security Considerations section, and it's too long. I'd suggest rephrasing it. Since you are talking about information that has higher security requirements, I'd just say it needs a higher level of protection in that case rather than using the word may. If it doesn't need a higher level of protection, this sentence doesn't apply to their decision process. How about... Change from: Information that might otherwise reveal private information about an individual, or where a level of authenticity needs to be guaranteed, may need a higher level of protection, and may indeed not be suitable for this package, particularly taking into account the statement in the following paragraph. To: Information that might otherwise reveal private information about an individual or where a level of authenticity needs to be guaranteed, requires a higher level of protection and may not be suitable for this package.
No response or discussion needed for any of this; just please consider: -- Section 2 -- This usage is not limited to scenarios where interworking will occur. Rather it describes a usage where interworking is possible if interworking is met. Say what? -- Section 6 -- The general principals of this package of the UUI mechanism are therefore as follows: "principles" -- Section 13 -- I'll make my usual comment that it's always seemed inappropriate to me to specify an individual, usually the primary editor of the document, as the contact for registrations done in working group documents. As this seems to be the norm in RAI documents (and has been done in other areas as well, including APP), that's all I'll say: just please consider specifying a role (such as email@example.com) instead.No response or discussion needed here. -- Section 15 -- Joanne McMillen was a major contributor and co-author of earlier versions of this document. We are allowed to use a "Contributors" section, which goes before the "Acknowledgments" section, to identify especially significant contributors, and such a section is particularly used to identify former authors. Might it be appropriate to do that here?
In this text from 10. Considerations for ISDN interworking gateways ISDN interworking gateways MUST support only the "isdn-uui" package on dialogs that are interworked. I'm confused as to whether this is saying that this package is only supported on dialogs that are interworked, or saying that this is the only package gateways support on dialogs that are interworked. Could you help me understand what's being intended? Either way - is this saying only if the gateway is doing interworking, as opposed to encapsulation?
Thanks for re-using PKIX algorithm identifiers instead of inventing new ones!
-- Section 5 -- This section povides three ways by which the responder can select an appropiate key pair type, but gives little guidance about how to go about the process. What happens if the different methods give different results? Should they be applied in a particular order? Why does this specification not cover this?
I have the same question as Barry.
I don't object to this document, but I found... > No known implementations of the protocol exist at this time. No > vendors have expressly stated a plan to implement this > specification either. ...a little odd for a Standard Track document, especially since there was apparently such clear consensus that this is a problem that needs to be solved. I guess I am old-fashioned enough to hope for running code from time to time.
A few weirdnesses in section 4: There can be multiple instances of the LMA User Plane Address mobility option present in the message, one for IPv4 and the other for IPv6 transport. Do you really mean "there can be multiple instances", or do you rather mean "there can be either one or two instances: One for IPv4, one for IPv6, or one for each of them"? ...the IP address field in the option can be either a zero-length field, or... Two instances of the above. Should that "can" be a MUST? ...the IP address field in the option MUST be set... In the above and the two bullet items below it: Shouldn't the "MUST be" in each one instead be "is"? There's no protocol requirement there. What else *could* an implementation do?
I have two questions. They could be easy or hard, I'm not sure:-) Apologies in advance if I've forgotten what little I ever knew about PMIPv6 and gotten stuff wrong here. (1) PMIPv6 traffic between MAG and LMA is generally assumed to be protected via IPsec, right? Assuming that's actually done, does figure 1 here indicate a weakening of security since it shows that IP encapsulation is used between MAG-UP and LMA-UP without any mention of IPsec. Is that downgrading security? I get that the binding messages are the most important and will presumably continue on the control plane but what else changes? (2) How does the rest of the Internet know to use the LMA-UP for the MN and not the LMA-CP? Sorry for being dense but I don't see how packets from a random Internet node for the MN end up going down the user plane.
Did you need to say somewhere which PMIPv6 messages are to be sent in the control plane and which in the user plane? That might be obvious to some, but its not to me and I guess there are a bunch of PMIPv6 extensions so I could imagine that someone somewhere might get it wrong.
I was surprised that I could follow all of this document. Good job by the authors! I have no objection to its publication, but I note a couple of points below that I think could improve the document. I shouldn't be surprised if the Security ADs pounce on something similar to the last point. --- The scaling problem described in Section 1 is real in as much as it is clearly a problem that deteriorates in a linear fashion with the number of services. Furthermore, the problem worsens in the product of the number of services and the number of nodes making discovery requests. This is all as described in the text. What is missing, however, is an explanaiton of why this is perceived to be a problem that needs to be solved. For example, if there is only ever going to be one service provided by one server, and only five nodes requesting the service then clearly nothing sophisticated is needed. The text in this section calls out four example services which suggests to the naif reader that growth to twelve service types might not be unreasonable. No clue is given as to the size of the cohort requesting discovery, nor to the multiplicity of service-providing nodes. It might, therefore, be interesting to enhance this section with some clues about current expectations of scaling requirements and also with an observation that we usually under-estimate scaling requirements in the Internet. --- If this document uses terminology from [I-D.ietf-p2psip-concepts], don't I need to read that document to understand this one? If so, that makes it a normative reference. --- In Section 4.5 the following text was slightly confusing... The fetched tree node is then analyzed and the next action determined by checking conditions 1-3. ...because (I think) this text is embedded in condition 1 of the 3 conditions. Perhaps "...by checking the three conditions set out here" or even "...MUST determine the next action by starting to check the conditions listed here starting at condition 1." Or maybe I was just confused and the text is OK :-) --- Why are there no security considerations? You are using existing (securable) protocol mechanisms to achieve a new function. Attacks on service discovery are likely to have "interesting" effects either denying services or redirecting traffic requesting a service to a false server. That means that you have defined some new threats (including, I think, the fact that requesting service discovery reveals a certain amount of information about the requester). Surely you need to describe these threats and explain how existing security mechanisms in the protocol are adequate protection.
- 4.3 step 5 - this implies that anyone can rewrite the Redir information for anyone else. Is that right? If so, why is that ok? I do see section 5, but I didn't get how that really works - can you explain? (To someone who's forgotten RELOAD mostly;-) - ISTM that the first sentence of section 9 is contradicted by the 2nd paragraph of section 9. I'd say just delete the first sentence there. (As noted by others.) - WRT the secdir review, I'm not sure SHA-1 is ok for the access control policy - can you explain why it is? (If we assume SHA-1 is broken for collisions.)
Nice read. Thanks.
Please Address the concerns pointed out in the SecDir Review: http://www.ietf.org/mail-archive/web/secdir/current/msg04958.html
Three points to discuss, please: 1. As Adrian points out, the terminology reference, p2psip-concepts, needs to be normative, if you really are using terminology thence. 2. As Adrian also points out, you're doing things here that have to create new security considerations. In fact, in the very next paragraph after you say it doesn't, you say that this creates a new access control policy. Is there really nothing at all to consider with respect to Section 5? 3. In Section 4.4, can you give at least some guidance about what "periodically" might mean? You say that it's up to each service provider to determine, but how can they determine that without at least a few words about the considerations involved, the issues that might come up, the tradeoffs, the consequences of choosing a time period that's too short or too long? Could I decide that, say, 20 years might be a suitable lifetime?
In this text appearing in 4.5. Service Lookups 1. If there is no successor of node n present in the just fetched ReDiR tree node (note: within the entire tree node and not only within the current interval) responsible for I(level,n.id), then the successor of node n must be present in a larger segment of the identifier space (i.e., further up in the ReDiR tree where each interval and tree node covers a larger range of the identifier space). Therefore, node n MUST reduce the current level by one to level=level-1 and carry out a new Fetch operation for the tree node responsible for n.id at that level. The fetched tree node is then analyzed and the next action determined by checking conditions 1-3. I'm guessing that "conditions 1-3" mean "this paragraph and the two following", but I'm guessing. If I'm guessing right, I wish that could be clearer ... perhaps it would help to label the three conditions as "Condition 1/2/3"? In this text appearing in 4.6. Removing Registrations Before leaving the RELOAD Overlay Instance, a service provider MUST remove the RedirServiceProvider records it has stored by storing exists=False values in their place, as described in [RFC6940]. Am I remembering that these records are soft state and will time out and be removed eventually anyway? If I'm remembering correctly, I'm wondering if this needs to be a MUST, or if it's just good advice.
This is probably explained in some ETSI document, but the sole distinction between PAT_error_count and PAT_error_2_count seems to be whether it reports the absence of a table of type 0, or the presence of a table not of type 0. The document explains that the two counts can't coexist, but doesn't explain why. If this is explained somewhere else, a reference to that document might be helpful. (I didn't find an explanation in section 5.2.1 of [ETSI], FWIW). Same observation applies for PMT_error_count.
I don't understand why an implementation MUST NOT send PAT_error_count if it has PAT_error_2_count, and vice-versa, and MUST NOT send PMT_error_count if it has PMT_error_2_count, and vice-versa. If I happen to have PAT_error_count in addition to PAT_error_2_count, what harm will come if I send both? If there is harm, shouldn't there also be a requirement that if you receive a block with both values, you MUST discard it? Please explain. It seems to me that these requirements are incorrect.
I have no objection to the publication of this document, but I wonder if anybody who is an MPEG-TS expert has reviewed this document? This is not clear from the sherpherd write-up.
I have a question on the security considerations and would like to discuss it to see if it can be improved in the current document. The Security Considerations Section references RFC3611. In RFC3611, confidentiality concerns are raised and it is good that they are spelled out explicitly. SRTCP is mentioned as a possible option, but says it is just in development. What's the current use of SRTCP and should there be a stronger recommendation for it's use in this new draft to address the confidentiality concerns? Or are there other measures that have evolved for confidentiality and DoS protections since RFC3611 was written. Thanks.
Pete covers the point I would raise.
Pete asked my question, also ...
I am balloting No objection on the basis of a very light review. I trust the responsible AD to have ensured adequate review. Here are some nits: --- You say: Operations, Administration and Maintenance (OAM) [OAM] But the cited document uses: Operations, Administration, and Maintenance (OAM) See also your Abstract. --- While you have correctly noted that Y.1731 is now G.8013/Y.1731, you should update your reference to the most recent edition. [ITU-T.Y.8013-2013] ITU, "ITU-T Recommendation G.8013/Y.1731: OAM functions and mechanisms for Ethernet based networks", ITU-T Recommendation G.8013/Y.1731, 2013. --- Section 1 These protocols generally conform to the performance monitoring functionality defined in ITU-T G.8013/Y.1731 [Y.1731]. "generally conform" is an odd term. Things either conform or they don't. So I interpret that some of the protocols conform and some don't, with the balance being that most of the protocols conform. That means a few don't and it would be good call out the specifics.
6.1: The figure says "TLVOffset", but the description says, "FirstTLVOffset". Fix one or the other. 6.2.2, 6.3.2, 6.3.3, 6.3.4: Your definitions for "Reserved" are screwed up. Some are missing, some are duplicated.
I have no objection to the publication of this document, and just two small issues you could look at as you progress the document. --- Section 3 is titled "Flag Bits: A Recommendation" however, the text is clear in its use of "MUST" and this a Standards Track document. I think you should change the title to "Flag Bits: New Processing Rules" Furthermore, in Section 1, you should not refer to this as a recommendation. --- In Section 4 you have text referring to ff1 such as: X and Y may each be set to 0 or 1. ... but no indication as to how or why these bits might be set. Are they or some specific use? Are they reserved like the r bits in ff2? Adding some clue or reference would be good.
Thanks for addressing the comments from the SecDir review. https://www.ietf.org/mail-archive/web/secdir/current/msg04886.html I have no additional comments.
-- Section 4.1.1 -- X and Y may each be set to 0 or 1. What does this addition mean? What, specifically, is the change it's making? I'd like to know the answer; more importantly, I think the document needs to be clear about it. (And the same goes for the similar lines in Sections 4.2.1 and 4.2.2.)
+1 to not bending over backward to accommodate SSLv3 :) Section 3. It would be helpful to note that the "+" symbol is being used to denote concatenation of octet strings, or use "||" as above.
Thanks for including Section 2.1. Also, I rather like the informal style (of Section 2.1, and of some other parts of the document). -- Section 5 -- IANA has added the extension code point 22 (0x16) for the encrypt_then_mac extension to the TLS ExtensionType values registry as specified in TLS . This doesn't say whether there are or aren't any actions for IANA, and it should. I think there actually is an action: to make the early-registration code point permanent.
Donald helpfully points out that my Discuss has confused > "TRILL Verison Sub-TLV" which is initially specified in > [RFC7176], Section 2.3.1 and > "the so-similar-as-to-be-confusingly named "Port TRILL > Version Sub-TLV" in Section 2.2.4 of [RFC7176]. ...so I am happy to clear my Discuss. The following Comments remain and are being discussed with the authors. === A recent conversation with an ITU-T OAM expert wrt a different I-D yielded the following. I think this aplies to your document, too. > Please note that the reference to Y.1731 is not correct. > Since the approval in 2011 the recommendation number > has changed to indicate that it is under responsibility of > SG15. Also the most recent version is dated 11/2013. > > So I suggest that the current reference: > [ITU-T.Y.1731-2011] > ITU, "ITU-T Recommendation Y.1731: OAM functions and > mechanisms for Ethernet based networks", ITU-T > Recommendation Y.1731, 2011. > Is changed into: > [ITU-T.Y.8013-2013] > ITU, "ITU-T Recommendation G.8013/Y.1731: OAM functions and > mechanisms for Ethernet based networks", ITU-T > Recommendation G.8013/Y.1731, 2013. --- You might look for consistency between "Ethertype" [RFC7174], and "Ether Type" and "EtherType" as used in this document. --- 3.2.1 Such frames MUST be discarded. Do you advise this to be silent, counted, logged? --- I think a short piece of text is needed (somewhere around 3.2.1 or 3.3?) to describe how a legacy implementation will react to receiving a frame with the A flag set. In fact, 3.3 of 6325 tells us about this, so most of this can be done by reference. But it is important in the context of OAM to consider what happens when the intended transit recipient of an OAM frame simply and legally forwards a packet. Similarly, it is important to consider what happens at an end station that does not recognise the A flag. Probably you would be noting in 3.3 that a legacy implementation will not know about the O and B flags to say that it does not support OAM, but that according to RFC 7176 those lags will be transmitted as zero so the absence of OAM support will be inferred. Furthermore, I think that the TRILL Version sub-TLV could be absent, so you need to state that this must be taken to mean that OAM is not supported. --- 3.2.1 Frames with the "A" flag set that do not contain CFM EtherType are not considered as OAM frames. Such frames MUST be discarded. No objection if you have thought through the consequences. In the future there is the posibility that a new use of the Alert flag will motivate the use of a diferent EtherType. However, in that case, you will not be able to get frames to pass through legacy nodes. That might be OK (all nodes on the path are assumed to have been upgraded) or very annoying (the new function is only needed at key RBridges on the path). I don't need to dicuss this: just be sure you are doing what you want to do. --- Format of 4.3.1 is messed up by tabs. --- I find it a little bit bothersome that this document and RFC 7174 uses slightly different terminology from that set out in Y.1731. For example, MEP is "MEP - Maintenance End Point" with a reference to [RFC7174] and [8021Q], while Y.1731 (and correlated in RFC 6371 etc.) has "MEG end point". Pretty sure this ship has sailed and that the authors will claim that allignment with 8021Q is more important than allignment within the IETF, but there you go... I'm bothered. --- I tend to agree with you in 6.1 that Hence, explicit addressing of MIPs is not required for the purpose of fault isolation. But I would like to raise the concern expressed by ITU-T OAM experts wrt multiple MIPs within a single RBridge. We saw this discussion in MPLS-TP (see RFC 7054) and it led to the need for some identification of MIPs. BTW, I think that, technically, you are talking about the addressing of MIPs in OAM request messages. I think that when a MIP responds it does need to identify itself, so you *do* need MIP identifiers. --- Shouldn't 8.1 describe the OpCode field? Just a smmary and pointer to 8.2. --- In 8.4.4 you have... Address Type (1 Octet): 0 - IPv4. 1 - IPv6. 2 - TRILL RBridge nickname. All other values reserved. Addr Length (1 Octet). 4 - IPv4. 16 - IPv6, 2 - TRILL RBridge nickname. Reply Address (variable): Address where the reply needed to be sent. Length depends on the address specification. The description of the Repply Address accurately states that the length of the field depends on the address specification, but that's not the future-proof model you are aiming for when you include the Addr Length field. I think you need... Address Type (1 Octet): 0 - IPv4. 1 - IPv6. 2 - TRILL RBridge nickname. All other values reserved. Addr Length (1 Octet). Dependent on the Address Type. Currently defined values are 4 - IPv4. 16 - IPv6, 2 - TRILL RBridge nickname. Other lengths may be acceptable for future Address Types. Reply Address (variable): Address where the reply needed to be sent. The length of this field is defined by the value of the Addr Length field. Also Length (2 octets) = Variable. Minimum length is 2. Surely you have to have at least a TRILL nickname, so the minimum value is 4 (Address Type, Addr Length, nickname). --- 8.4.5 needs to describe the Reserved field. Maybe best to take the text in 8.4.3 and lift it to some common part of the document where you can say "all fields in this document marked as reserved..." --- 8.4.7 and 8.4.9 Length (2 octets) = variable. Minimum value is 2. Surely 1. That is nOfnicknames could be set to 0. Also, please describe the nOfnicknames field and clarify how it relates to the Length field. --- 8.4.8 Length (2 octets) = 4. Are you sure? it looks like 5 in the figure. --- 8.4.12 Length (1 octet) =97. 8.4.13 Length (1 octet) = variable length I think it is a 2 octet field in both cases. --- 10.1.2 provides a list of TLVs for inclusion. The way this is presented implies that the ordering is sensitive. The text should clarify this point. Similar issues in other sections.
- 8.4.13 - can you explain why automated key management (see BCP107) is not needed here? I don't see how the symmetric keys required would get to all the relevant boxes, or at least I don't see that specified here or a reference that I can access.
- 8.4.4 - is there a possible DoS issue here? - 8.4.13 - why is an authentication TLV OAM specific? - 8.4.13 - I don't (think I have) access to [IS-IS] so I've no idea how this works in general - why not just say that rfc5310 is must-implement and [IS-IS] is a MAY? And why not go further and make HMAC-SHA256 the MTI auth type? - Section 14 says: "Generally, a single operator manages each TRILL campus, hence there is no risk of security exposure." I think that's just bogus if you're trying to say that there are no security issues in managing a campus network. But I guess that's not it, so what are you trying to say?
Thanks for writing this document. I've read through it (not claiming full understanding), and only had two small comment: There are several statements of the form: The CPU of the RBridge validates the frame ... While this represents the typical implementation, or perhaps even the only reasonable implementation at this point in time, I'd suggest that an IETF specification should not dictate what part of an implementation performs packet validation and other tasks. Just saying the RBridge validates the frame should be enough, in my opinion. Also, the document has statements of the form: Registry: TRILL OAM Return Codes. Registration Procedure: Standards Action. and I believe it would be useful to reference RC 5226 for understanding what is meant by the various procedure names.
Piling on with Adrian: 8.4.3: Length is 9, not 6. Also, it would be useful to indicate the first "Reserved" field is 3 octets, and the second is 12 bits. 8.4.10: Like 8.4.5, you never define Reserved.
I may have missed it, but didn't see any mention in the security considerations section of network reconnaissance activity using the path trace, CCM, and other techniques described to map networks (path and endpoint/RBridges) to be used later in exploits. I may have missed this, but did also check the referenced RFCs (7174 & 6325), please let me know if I missed something. Reconnaissance could be active by an attacker using the described techniques to discover the network or could be a passive observer collecting data from valid uses of the described techniques.
This extension was previously published as experimental. There is now implementation experience, giving confidence in the protocol, so this document puts the extension on the Standards Track, with some minor updates that were informed by the implementation experience. [[RFC Editor: Please remove this paragraph at publication.]] The list of implementations is apparently one, which is not in widespread use. I mention this not to argue against reclassification. But: The client SHOULD NOT provide source options that resolve to including the same mailbox more than once. A server can, of course, remove the duplicates before processing, but the server MAY return "BAD" to an ESEARCH command with duplicate source mailboxes. This sounds a little tenuous to me, and I wonder if it's not the result of some implementors making an engineering decision and then deciding to mention it in the RFC as advice. ISTM that it's actually not unreasonable to expect two mail box terms to identify an overlapping set of mailboxes, and in such a case it would be very desirable for the server to eliminate the duplicate rather than rejecting the command: that is, it is easier for the server to know that such a duplication exists than for the client to know, and therefore requiring the client to prevent this error is more onerous than requiring the server to prevent the error. ISTM that the right advice here is "the server should notice and eliminate duplicates when searching, and MUST NOT return BAD." However I assume there was vigorous discussion on the working group mailing list that reached the conclusion presented in the current text, and eagerly await explanation as to why I am wrong about this. :)
I have no objection to the publication of this document, but please consider my one suggestion below. (Also a homily for the delectation of future generations.) --- In section 1 This extension was previously published as experimental. There is now implementation experience, giving confidence in the protocol, so this document puts the extension on the Standards Track, with some minor updates that were informed by the implementation experience. [[RFC Editor: Please remove this paragraph at publication.]] To the contrary, I think you should retain this paragraph and use it to record how/why this document obsoletes 6327 with the inclusion of a forward-pointer to section 8. --- I appreciate your use of RFC 6982 (because I get commission), but the information you included is not overwhelming or very detailed. Nothing to be done at this stage, but next time...
Thanks for discussing my concerns around logging. I'm okay with that being left as an implementation choice (not mentioned in the draft), but do think it would be helpful to have it for testing access controls as well as detection of unapproved access attempts.
One question, at most a nit. In the Abstract This extension also uses MAILBOX and TAG fields in ESEARCH responses, ^^^^^^^ ^^^ allowing a client to pipeline the searches if it chooses. This document updates RFC 4466 and obsoletes RFC 6237. but in 1. Introduction o The MAILBOX, UIDVALIDITY, and TAG fields in the responses allow a ^^^^^^^ ^^^^^^^^^^^ ^^^ client to distinguish which responses go with which search (and which mailbox). A client can safely pipeline these search commands without danger of confusion. The addition of the MAILBOX and UIDVALIDITY fields updates the search-correlator item defined in [RFC4466]. I'm only pattern matching, but should these lists of fields match? Or am I not understanding (which is likely)?
Thanks for including the RFC 6982 section!
Section 2: "A server that supports this extension includes "MULTISEARCH" in its IMAP capability string." This jumped out at me as I would have expected a statement like this to be a normative requirement, rather than a statement of fact.
This mechanism relies on there being no MiTM attack from a compromised signing key either prior to a legitimate pinning, or in a situation where the host being "protected" doesn't actually do pinning. I think this should be mentioned in the security considerations section. I raise this to the level of DISCUSS because I think this actually creates a new attack surface for government censorship: you MiTM the host you're attacking, pin it to a cert signed using a compromised CA, and then that UA can't communicate with the host again for the duration of the pin. The scenario would be that the government has a transparent web cache in the path between the host and the UA, and the web cache pins false cert for hosts that are being censored. Now even if the user sets up a tunnel to bypass the transparent cache, they can't access the censored site, so they conclude that the site is down and abandon the tunnel. I could easily see this being used in a scenario like the recent DNS censorship in Turkey. Setting a lower maximum pin age mitigates the damage of such attacks if the user keeps the tunnel up for the duration of the pin, but I don't think it's realistic to assume that they will. I think that the only way to mitigate this attack is to have a mechanism whereby conflicting DANE TLSA information overrides the pin. This would allow a site being attacked in this way to securely inform the UA that the pin was invalid. The government could of course prevent DNSSEC validation, but the UA could take this as another signal to drop the pin: if the zone where the TLSA record should be fails to validate (as opposed to isn't signed, which wouldn't signify anything), the pin is likely a censorship attempt.
1: The first sentence is quite confusing. Might I suggest instead: This document defines a new HTTP header that enables user agents (UAs) to determine which Subject Public Key Info (SPKI) structures will be present in the web host's certificate chain in future TLS [RFC5246] connections. 2.1: Public-Key-Directives = [ directive ] *( OWS ";" OWS [ directive ] ) Are you sure that's correct? First of all, it may be completely empty. That seems like something you wouldn't want. Second of all, it allows for semicolons without directives between them, which may or may not be what you want. It's not clear to me why you made this semicolon-delimited instead of comma-delimited, which would be much more in line with the rest of HTTP. Then you'd simply get: Public-Key-Directives = 1#directive But if you insist on semicolons, you want either: Public-Key-Directives = directive *( OWS ";" OWS directive ) or if you want to allow for empty elements: Public-Key-Directives = *( ";" OWS ) directive *( OWS ";" [ OWS directive ] ) If the following is acceptable: Public-Key-Directives: ;;;;; then your original is fine. s/hahs/hash 10.1: Update 4627 to 7159 I think W3C.REC-html401-19991224 is informative. This document says that you MUST NOT do what's in that document.
Good doc. Two things I'd like to check before moving to a yes ballot: (1) 2.1 - Can a simple-directive start with "pin-"? Seems like yes it can, but then the ABNF is ambiguous about the RHS of the "=" I think, is that right? Its no big deal since valid values will parse anyway, so only an issue if you ever care about simple-directive vs. pin-directive. Ah - does the last para of 2.1 mean that this distinction is needed really? (2) 2.1.3 says that "If the scheme in the report-uri is one that uses TLS (e.g. HTTPS), UAs MUST perform Pinning Validation when the host in the report-uri is a Known Pinned Host;" That's generally ok, however, I think it may break for alt-svc, where TLS is used but https is not, or if TCPINC decided on a TLS based solution then some coder might get it wrong. I think a simple re-statement in terms of http vs. https URIs should fix this. I realise that neither alt-svc nor TCPINC existed when this work started, but since they now do it'd pay to think about them and I don't recall seeing that on the websec list (apologies if I'm wrong there). The IFF in 2.5 also seems related. 2.2 has same issues about alt-svc and TCPINC. I do see that you only say "e.g. TLS" here but wonder nonetheless, e.g. would 2.2.1 cover an alt-svc case or not?
abstract and elswhere: SubjectPublicKeyInfo doesn't usually have spaces between the terms. No big deal. After the abstract would a ref to 5280 be right for SPKI as well? general: I think emphasising the backup pin requirement in the intro would be good. It's a little hidden now and would be a surprise to some I bet. 2.1 - pin-directive has the literal "pin-" but later you say (in bullet #3) that directive names are case insensitive. Does that apply to "pin-" as well or not? 2.1 - has some typos: reistry and hahs 2.1 - "Known Pinned Host" would be a fine term to define in a section 1.1 that was renamed via s/Requirements Language/Terminology/ 2.1.1 - max-age is really defined against the time of reception and not (in principle) from when its emitted? I know that makes no difference now, but with a sufficient latency (e.g. Earth->Mars, min 4 mins, max 20 mins, and yes my DTN heritage is showing:-) it could, just about. I think to be pedantically correct, max-age ought be defined versus the time of emission and not receipt. 2.1.2 - uses the term "Pinned Host" which is not the same as the previously used "Known Pinned Host" - is the distinction meant to be significant or is that a typo? 2.1.3/section 4 - shouldn't the potential DoS issues be discussed for cases where report-uri != same-origin? E.g. if busy-site.example.net (is hacked and) sets report-uri to victim.example.com (maybe with some HTML/JS that generates loads of queries to the victimj) that'd be like getting /.'d I think that's maybe worth noting in the security considerations or in 2.1.3 where you (quite properly) say to rate-limit reporting. If you'd rather not say why though, that's ok too.
This is an important document, and overall clearly written. There are a few points that it would be good to clean up. Introduction: "At least one UA..." FWIW, this is now "At least two UAs..." Firefox also has a manual pin list as of version 32, currently in Beta. Introduction: "but is possible to pin keys without requiring HSTS" -> "but it is ... and vice versa." Section 2.2.2. "Pinned Hosts SHOULD NOT include..." This applies not just to Pinned Hosts, but to any web host, right? Section 2.3.1. "If a UA receives more than one PKP header field ... only the first PKP-RO header field (if present)" This seems problematic in light of the fact that HTTP recipients are allowed to coalesce the values of multiple header fields. http://tools.ietf.org/html/rfc7230#section-3.2.2 So, for example, if header coalescing were done at a lower layer in the HTTP stack than HPKP, then the pinning code wouldn't be able to distinguish "first" vs. "rest". On the other hand, maybe this is a use case for using semicolons as separators, since the combined header field would not be valid. In either case, there's a need for updated text. Section 2.5. "at least one Pin that does NOT refer to an SPKI in the certificate chain" I understand the motivation for this, but this doesn't actually force the site to have a backup pin -- they can just make up a pin value. It seems like it would be more effective to make the recommendation in Section 4.3 stronger. Section 4. "Security Considerations" Most of these seem more like "Operational Considerations" or "How-To-Not-Brick-Your-Site Considerations". :)
Overall the draft is very good, thank you for writing it. I just wanted to discuss some of the security/privacy considerations and see if we could improve the language and make sure the set of concerns are clear. The privacy consideration section reads more like possible attack scenarios that would fit into the security considerations. What privacy related concerns result from these attacks? Having that spelled out to differentiate the risks as privacy only would be helpful (if appropriate) or moving this into the security consideration section *IF* it is more generically applicable. If I am missing something and this is only privacy related, it would be good to understand that in this discussion. Adding some text on how these attacks could be used to expose privacy related information would be helpful too. For the first example, it seems it is the possibility that a report goes outside out the intended scope is the concern. The mitigation seems to be provided in the last sentence of #4, but couldn't this be other information leakage and not just privacy? Let me know if I am missing something that explains why this is privacy specific. In #3 of the second example, the last sentence includes the following clause: and giving some UAs no Valid Pinning Header for other subdomains (causing subsequent requests for m.fingerprint.example.com to succeed). Does this mean that these subdomains are succeeding when they should fail? It might just be me, but that is not clear in the text (or if they are supposed to succeed). It sounds like they are not supposed to succeed and this is the security issue. How is this privacy specific? Again, this may just be me, but an explanation would be helpful. In the last sentence of the privacy considerations section, what is meant by the description "forensic attacker"? I find this term confusing. Was this intended to mean that techniques used in forensic analysis could be used by an attacker to discern information that could be of interest? If that's the case, I think it would be clearer to the reader if that were stated instead.
I agree with Richard's comment that the document is well written and an important document, thank you for writing it. The style changed a little toward the end and I had some trouble with long sentences in the security & privacy considerations sections. This should be easy enough to fix and may be done with the RFC editor anyway. To Richard's point on operational concerns versus security concerns, are there explicit security attacks that could occur with the max-age variations described? In 4.2, I can't see this being more than an operational concern since it fails when overlapping pin sets are not used. Are we missing a gap that leads to a security concern? 4.3 makes sense to me as a security concern that drives operational practices.
I agree with Pete's Comments.
I agree with Pete's comment about the first sentence. It would be nice if in Section 5 or 7 some suggestion could be made for UAs to consider the relationship between the functionality they provide to clear pins/pinned hosts and the functionality they provide to clear (or prevent the storage of) other UA state. E.g., upon clearing one's browsing history or entering private browsing mode, it seems like having the option to clear pins/pinned hosts or not pin would make sense. This is alluded to in Section 7 but not really tied to the threat described in Section 5. I'm also curious about whether there is any reason to retain expired pins? (Other than the fact that flushing them requires the UA to actively check which ones are expired.)
Senders of abusive mail often use forged undeliverable return addresses. Null MX allows DSNs and other attempted responses to such mail to be disposed of efficiently. What's a DSN? Please define in the terminology section, or add a reference saying that the reader should read (X), or just expand on first use: not all readers will have the SMTP RFCs memorized. :) Also, it's not clear to me how this is a win unless the forged undeliverable return address has a null MX. Is that the envisioned scenario? If so, an additional sentence or two explaining why this is likely would help to justify the existence of this paragraph; otherwise I recommend just deleting it--it's not necessary, and on the face of it it seems implausible, but I'm not a spam expert, so maybe there's a reason of which I am not aware that the spammer would set this up, or use a fake domain for which a null MX exists.
I have no objection to the publication of this document and you'll probably call me picky when I point to the last line in Section 3. A domain MUST NOT advertise multiple MX RRs including a null MX. That says one of two things: 1. You must not advertise multiple MX RR if any one of them is a null MX. 2. You must not advertise more than one null MX, but may advertise one null MX along with other MX RRs. I think you mean the former in which case... A domain that advertises a null MX MUST NOT advertise any other MX RR. But, if you meant the latter that could also be clarified.
Just curious - do we know or are we guessing that this won't be an issue for DNSSEC (implementations)? I've no info either way, so its purely curiosity, really:-)
It seems like it would be worth documenting the fact that this is likely to result in increased bogus traffic to the DNS root. Just because "." is technically not valid doesn't mean that some DNS libraries won't accept it. For example, `dig . A` will happily send a query. But the root is already used to dealing with noise, and in exchange for increasing that noise floor a little, we get to potentially reduce mail noise by a lot. So the trade-off is worth making, but it would be nice to document it.
Version -07 added the downref to RFC 1846. 1. We intend to move 1846 to Standards Track. That should happen quickly, but... 2. ...just to cover bases here, I intend to do a second last call on this document solely to call out the downref. That way, even if the 1846 update doesn't go quickly, we're covered.
Section 4.1 uses the acronym "DSN" without any expansion. I assume this expands to Delivery Status Notification, which is used later in the section.
After following the long email thread and discussing this with the document editor, I come to the following proposed changes. The net effect is to note that with "Expert Review" the concept of "Early Allocation" is not needed because the Designated Experts are empowered to grant assignments when they think appropriate. What *is* useful, however, is to give those experts some guidance about what is and is not appropriate. That leads me to the following... Abstract OLD This document recommends some editorial changes to the IANA IS-IS TLV Codepoints registry to more accurately document the state of the protocol. It also defines early allocation procedures for codepoints managed by the registry. NEW This document recommends some editorial changes to the IANA IS-IS TLV Codepoints registry to more accurately document the state of the protocol. It also sets out new guidelines for Designated Experts to apply when reviewing allocations from the registry. END Section 1 OLD The IS-IS TLV Codepoints registry was created by [RFC3563] and extended by [RFC6233]. As IS-IS related RFCs are published the codepoints required for the protocol extensions are added to the IANA managed registry. NEW The IS-IS TLV Codepoints registry was created by [RFC3563] and extended by [RFC6233]. The assignment policy for the registry is "Expert Review" as defined in [RFC5226]. As IS-IS related documents are developed, the codepoints required for the protocol extensions are reviewed by the Designated Experts and added to the IANA managed registry. As these documents are published as RFCs, the registries are updated to reference the relevant RFC. END Section 1 OLD There is a need to support early allocation of codepoints defined in drafts which seem likely to eventually gain WG approval. The procedure for obtaining early allocation of codepoints is described. NEW In some cases there is a need to allocate codepoints defined in Internet-Drafts which seem likely to eventually gain WG approval without waiting for those drafts to be published as RFCs. This can be achieved using Expert Review, and this document sets out guidance for the Designated Experts to apply when reviewing allocations from the registry. END Section 4 OLD 4. Early Allocation of Codepoints When new drafts are introduced requiring new codepoints, it is advantageous to have the ability to do early allocation of codepoints. The reasons this is advantageous and the process to do so is described in [RFC7120]. However, [RFC7120] procedures do not apply to registries such as the IS-IS TLV Codepoints Registry which utilize "Expert Review" allocation policy. In such cases what is required is that a request be made to the designated experts. The following procedures are defined. Note these procedures apply specifically to the IS-IS TLV Codepoints registry. This document is not defining a general early allocation process for other Expert Review registries. 1. In order to qualify for early allocation a draft MUST be accepted as a WG document 2. The author(s) of the draft MAY request early allocation of codepoints to the chair(s) of the WG in which the document is submitted 3. The WG chair(s) gauge whether there is consensus within the WG that early allocation is appropriate for the given document and that the conditions for early allocation specified in [RFC7120] Section 2 are satisfied. If so the request is forwarded to the Area Director(s). 4. If the Area Director(s) approve, the request is forwarded to the Designated Experts for their approval. 5. Once the Designated Experts have granted approval IANA will update the registry marking the allocated codepoints as "Temporary" following the procedures specified in [RFC7120] Section 3.1 NEW 4. Guidance for Designated Experts When new drafts are introduced requiring new codepoints, it is advantageous to be able to allocate codepoints without waiting for them to progress to RFC. The reasons this is advantageous is described in [RFC7120]. However, [RFC7120] procedures for early allocation do not apply to registries such as the IS-IS TLV Codepoints Registry which utilize "Expert Review" allocation policy. In such cases what is required is that a request be made to the Designated Experts who may approve the assignments according to the guidance that has been established for the registry concerned. The following guidance applies specifically to the IS-IS TLV Codepoints registry. 1. Application for a codepoint allocation may be made to the Designated Experts at any time. 2. The Designated Experts should only consider requests that arise from Internet-Drafts that have already been accepted as Working Group documents or that are planned for progression as AD Sponsored documents in the absence of a suitably chartered Working Group. 3. In the case of Working Group documents, the Designated Experts should check with the Working Group chairs that there is consensus within the Working Group to make the allocation at this time. In the case of AD Sponsored documents, the Designated Experts should check with the AD for approval to make the allocation at this time. 4. The Designated Experts should then review the assignment requests on their technical merit. The Designated Experts should not seek to overrule IETF consensus, but may raise issues for further consideration before the assignments are made. 5. Once the Designated Experts have granted approval IANA will update the registry marking the allocated codepoints with a reference to the associated document as normal. END
Thank you for taking the time to write this document. --- I don't understand why this document includes a "pre-November 10, 2008" disclaimer. Could that safely be left out? --- The Abstract says that the document "recommends" some changes. That may have been true as an I-D, but will not be true as a published RFC. Probably s/recommends/makes/
Get-ART reviewer Robert Sparks concurs with Pete's observation about the weirdness of PS classification, but it may not be so important (IMHO) to fix this. Lets focus on other things, like Adrian's Discuss.
Slightly weird to have this be Standards Track.
Adrian has this covered.
I support Alissa's point (and Adrian's soon-to-be points).
I'm a little confused about the state in which this document leaves the registration policies, so maybe someone can clarify. I think what this document says is that to obtain an early allocation in the IS-IS TLV Codepoints registry, an IETF WG document is necessary (along with a bunch of other things including WG consensus, AD approval, and DE approval). But since the policy for non-early (final) allocations is expert review and there does not seem to be any explicit document requirement, it's possible that a final allocation can be made based on an individual draft or a document from another SDO, or with no document at all. Is that the desired outcome? It seems a bit backwards in that on paper it might be easier to get a final allocation than an early one.
I have no objeciton to the publication of this document. Here are two small editorial points you may want to consider. --- Whenever I see an Abstract like this one (and the corresponding paragraph in the Introduction) I wonder how it will read as an RFC rather than as an Internet-Draft. As part of an I-D it is fine to say "there is at present..." but in five years time, when you read the RFC it will seem really odd. Why not go for the more simple statement... This document registers code points to allow status codes to be returned to an email client to indicate that a message is being rejected of deferred specifically because of email authentication failures. --- I would prefer that the Abstract also indicated how this document updates RFC 7208. Thus... This document updates RFC 7208 to register code points to allow status codes to be returned to an email client to indicate that a message is being rejected of deferred specifically because of email authentication failures.
- Since only one code is returned and since the client has to assume that other failures may have happened in parallel, and since the X.7.20 code covers two different things (i.e. (a) and (b) from 3.1), did the wg consider splitting out 3.1's (a) and (b) into different codes? That way the 3.1.a code would conform to 6376 and the 3.1.b code would be "failed my local DKIM specifics." Seems to me that splitting those out might be better but I'm fine if this was considered and rejected (i.e. no need to re-do the reason for rejecting, just tell me it happened and that'll be fine). - The intro could make the X.7.nn notation clearer, but it becomes blatently obvious if one reads 5248 so its ok unless you want to be extra-nice to the reader.
As someone who has had to debug SPF-related mail failures, I approve this message.
No objection to the publication of this document, but I have one comment that I would like considered. It may be useful to provide an explicit link to the IANA registry being updated. That could easily be done by including http://www.iana.org/assignments/smtp-enhanced-status-codes in the IANA Considerations section. It would also be clearer of section 6 referred to the SMTP Enumerated Status Codes registry rather than the SMTP Enhanced Status Code Registry.
I should have liked this document to include a short section describing the changes since 4614, but it is probably not important.
Thank you for updating the TCP Roadmap, this is a very helpful document! My only question is if there will be work to update references to this once published so that the intended audience is aware of the document? I see rfc4614 referenced in places like Wikipedia's page for TCP. No need to get back to me on this.
Nice; thanks! It's odd that you got the text updated for RFC 7323, but the reference is still to the draft. The RFC Editor will fix that, but if you're making other updates, you might want to fix it yourself.
Thank you for doing this important update. I'm sure it wasn't easy. I had some questions, but nothing we need to discuss. Please consider these along with any other feedback you receive and do the right thing. In this text: Note that the category of an RFC does not necessarily reflect its current relevance. For instance, RFC 5681 [RFC5681] is considered part of the required core functionality of TCP, although the RFC is only a Draft Standard. Similarly, some Informational RFCs contain significant technical proposals for changing TCP. Now that we've stopped using Draft Standard when advancing along the standards track, but we left existing Draft Standards in place, this unchanged text doesn't make as much sense (to me) as it did in 2006. If you dropped out the "For instance" sentence completely, you'd still be making the stronger point about Informational RFCs being relevant to a protocol that's a full Standard anyway. In this text (but in a bunch of similar places): RFC 1122 S: "Requirements for Internet Hosts - Communication Layers" (October 1989) This document [RFC1122] updates and clarifies RFC 793 (see Section 2), "see Section 2" is ambiguous enough to refer to (1) RFC 793, (2) RFC 1122, or (3) the current draft. I can figure out which one you mean, but since you've added these section references since 2006, I'm sure you're trying to make things less vague, rather than more vague. Is it possible to use a less ambiguous style, perhaps "(see [RFCwhatever] Section 2)" - or whatever the format is that would give the reader hyperlinks to make chasing the cross-references easier in the HTML version ... In this text, RFC 5681 S: "TCP Congestion Control" (August 2009) Although RFC 793 (see Section 2) did not contain any congestion control mechanisms, today congestion control is a required component of TCP implementations. This document [RFC5681] defines the current versions of Van Jacobson's congestion avoidance and ^^^^^^^ control mechanisms for TCP, based on his 1988 SIGCOMM paper [Jac88]. is "current" the right word in 2014? More broadly, I wonder if Although RFC 793 (see Section 2) did not contain any congestion control mechanisms, today congestion control is a required component of TCP implementations. This document [RFC5681] defines congestion avoidance and control mechanisms for TCP, based on Van Jacobson's 1988 SIGCOMM paper [Jac88]. might be a better phrasing. In this text: RFC 3465 E: "TCP Congestion Control with Appropriate Byte Counting (ABC)" (February 2003) This document [RFC3465] suggests that congestion control use the number of bytes acknowledged instead of the number of acknowledgments received. The ABC mechanism behaves differently than the standard method when there is not a one-to-one relationship between data segments and acknowledgments. Would you consider a TCP to have a "one-to-one relatioship between data segments and acknowledgments" if it does delayed ACKs? I think I know the point you/re making, but I'm not sure if I understand this text. In this text in section 4. Experimental Extensions At this point is worth mentioning that if the experimental RFC is a ^^ proposal for a new protocol capability or service, i.e., it requires a new TCP option code point, the implementation and experimentation should follows [RFC6994] (see Section 5), which describes how the ^^^^^^^^^^^^^^ experimental TCP option code points can concurrently support multiple TCP extensions. This might just be "it is worth mentioning" and "should follow" but the sentence structure was complicated enough that I wasn't sure I was following. In this text in section 4.2. Fundamental Changes Like the standard documents listed in Section 3.1 there newly exist also experimental RFCs that represent fundamental changes to TCP. I just can't parse it. I can guess what it means, but I'm guessing. Perhaps In addition to the standard-track documents listed in Section 3.1, there are also experimental RFCs that represent fundamental changes to TCP. In the same paragraph, One example is TCP Fast Open that deviates from the standard TCP semantics of [RFC0793]. It's OK with me if you only include one example, but is there a good way for someone not skilled in the art to find other examples of proposals for fundamental changes? And if you don't have a ready answer, you might reasonably ask me/Martin the same question ...
This is a simple Discuss as a place-holder for IANA's issues. I see Rajeev's email answering IANA's questions, but the document hasn't been updated accordingly. This needs to happen before the document can be approved. I don't suppose that these changes will be controversial, but since this defines how future allocations can be made, it should at least be shown to the working group. The AD will (of course :-) want to cause a Management Action to identify the Designated Expert for the new registry. [A hint here - The shepherd review says "No new registeries (sic) need to be created" and so misses these points.]
Thank you for addressing the SecDir review and adding text in the Security Considerations section on the concern described. https://www.ietf.org/mail-archive/web/secdir/current/msg04911.html
-- Section 1 -- This document refers to [RFC6459] for the basic definitions of mobile network terminology (such as APN) used here. I think that makes 6459 a normative reference, don't you? Please also reconsider whether 3748 should be normative. And I think the use of 5226 in Section 7 makes it normative.
-- Section 2 -- The section title seems to be from an old version; please fix it. -- Section 5.2 -- In turn, the network provides what is supported. Do you mean to say, "provides a list of what is supported." ? -- Section 7 -- A specification would be required to request assignments from this registry; see [RFC5226]. The usual way to specify a well known registration policy from 5226 is to use its capitalized name exactly. I'd prefer to see that: NEW New assignments in this registry are made with the Specification Required policy [RFC5226]. END
I don’t really see the justification in this draft for standardizing AT_MN_SERIAL_ID, which can contain a rather privacy-sensitive identifier (IMEI) given that it’s a permanent device ID. Even if 3GPP networks use it for authentication, if the Wi-Fi network is trusted I don’t see why that creates a need for the new EAP attribute for the use cases given in this draft.
Several ADs have requested that there be some serious thought given to security considerations in active-active scenarios. I think this is a reasonable request. I'm raising this as a DISCUSS because I would like the working group to consider this before the document advances.
I have no objection to the publication of this document, but here are some points you may want to discuss with your document shepherd and responsible AD. --- CE - As in [CMT], Classic Ethernet device (end station or bridge). The device can be either physical or virtual equipment. 1. [CMT] has "Classical Ethernet device" 2. I am aware of World Acronym Depletion (WAD) , but do you think it is advisable to use "CE" when that abbreviation has such a well- known meaning that shows on figures in a way that is highly similar to the positioning of your CE on your figures? --- As a problem statement, I feel you are dodging an issue when you write LAALP is usually a proprietary facility whose implementation varies by vendor. So, to be sure the LAALP operations successfully across a group of edge RBridges, those edge RBridges will almost always have to be from the same vendor. In order to have a common understanding of active-active connection scenarios, the assumptions in Section 2.1 are made about the characteristics of the LAALP and edge group of RBridges. and Other than the applicable characteristics above, the internals of an LAALP are out of scope for TRILL. Shouldn't you actually be raising this as a missing component in the toolset? A standardised LAALP would increase the flexibility and utility of TRILL in a multi-vendor environment. Your document could briefly explain how initial deployments will be proprietary, describe the limitations, state that a standardised LAALP would be beneficial, and briefly outline what such a protocol might look like (presumably built on MC-LAG) and how it needs to differ from existing offerings. You already have lots of this material, but it seems you are actively discouraging work on this topic. I can see that this might be out of scope for the current TRILL charter, and whether someone comes along later to address the requirements is for the future, but you seem to be pushing a deployment scenario where a CE can only be attached to an edge RBridge from the same vendor. --- I find section 5 disappointing! Although (of course) solution-specific security issues can only be documented in the solution documents, I should think that the active-active model introduces some interesting security issues. If the new function/architecture genuinely introduces no issues or security associations, then that is fine: I am just surprised by the fact. --- It would be nice, IMHO, if this document also described the manageability requirements to support active-active. Are there changes to OAM? How does one find out which edge RBridge is carrying which flow? What needs to be configured/inspected at the CE and the edge RBridge?
I second Adrian's point, the same one made in the SecDir review. While individual solutions may have specific security concerns or risks, I would think that there are some risks that would broadly apply to ant solution that should be described here and perhaps even setting security requirements for any solution that follows. https://www.ietf.org/mail-archive/web/secdir/current/msg04939.html
I didn't see a response to the SecDir review and think there was a good catch in the review that is worth discussing to see if some text should be added to the Security Considerations section. The request was to put more into the security considerations since this is a requirements draft. The problems would be addressed in the specific solution drafts, but it would be good to call these issues out as security considerations for those solutions. Possible text: Security considerations for any proposed solution should consider exhaustion of resources related to preemption, especially by a malicious actor as a threat vector to protect against. Protections should also be considered to prevent a malicious actor from attempting to cause an alternate path to force traffic by a sensor/device, thereby enabling pervasive monitoring [RFC7258]. Here is the SecDir review for reference: https://www.ietf.org/mail-archive/web/secdir/current/msg04864.html
Could you add a small amount of text into the introduction so that it is clear that the term protection used in this draft is referring to survivability or availability? Or a reference to it would be helpful as was done in the second paragraph of the introduction of RFC6378. Text is preferred though since this should be very simple to address with a few words. As a security person, I was mapping out paths and trying to figure out if certain resources had special properties I didn't see described anywhere until I got a bit further into the draft to realize they were really just alternate paths. I am sure this wouldn't be an issue for those well-versed in MPLS, but could be helpful for the rest of us.
Could figure 1 be placed after the first paragraph of Section 3? This would make it easier to look at the figure while reading the description that comes before and after the figure.