IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2017-03-16. These are not an official record of the meeting.
Narrative scribe: John Leslie, Susan Hares, and Ignas Bagdonas (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
2.2 Individual submissions
2.2.1 New items
Telechat:
Telechat:
2.2.2 Returning items
2.3 Status changes
2.3.1 New items
2.3.2 Returning items
2.3.3 For action
Telechat:
3. Document actions
3.1 WG submissions
3.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
Telechat:
Telechat:
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
Telechat:
3.4.2 Returning items
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
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
7. Working Group News
7a. Other Business
1159 EDT Adjourned
(at 2017-03-16 06:00:16 PDT)
draft-ietf-jsonbis-rfc7159bis
Text about mandatory to implement charset encodings or charset auto-discovery need to be added back to the document. Alvaro: I think you are correct. I've added an RFC Editor note.
- section 9: This allows limits for nesting depth, number range and precision, and string length. Can you offer any guidance about what sorts of limits might be reasonable? Or what limits might unreasonably impact interoperability? - 12, 2nd paragraph: This paragraph sort of buries the lede. I thought it was going to talk about the implications of not being able to parse certain JSON legal characters with eval(), but I understand it really about the risk of arbitrary executable content. I suggest you say that in the first sentence.
I don't see a response to the first part of the SecDir review on the Security Considerations section. Given the content of the current security considerations section, I agree with Ben that the additional considerations he mentions should be included. Can someone respond to Ben please on that part of his review? Thank you.
If rfc7159 already Obsoleted rfc4627 and rfc7158, and this document Obsoletes rfc7159, does it need to be marked as Obsoleting rfc4627 and rfc7158 again? I would think that it doesn't.
draft-ietf-ipsecme-rfc4307bis
(oops, meant to ballot "yes". Fixed now.) Section 2.1, 2nd to last paragraph says that ENCR_3DES has been downgraded to SHOULD NOT. But both the table in this section, and the change table later in the draft say MAY.
Here is Sue Hares' OPS DIR feedback: Status: Read for publication with editorial nits (see below) General Comment: Thank you for this interesting, informative, and well-written draft. My editorial nits are just places you might improve the clarity of the draft. Sue Hares ======================= Editorial Nits: #1 – Section 1.3, p 4, paragraph 1 Old/The recommendations of this document mostly target IKEv2 implementers as implementations need to meet both high security expectations as well as high interoperability between various vendors and with different versions. / New: /The recommendations of this document mostly target IKEv2 implementation as implementations need to meet both high security expectations as well as high interoperability between various vendors and with different versions. / Note: Either implementation as implementations Or implementers as implementers need to create implementations #2 – section 1.3, p. 4,paragraph 2 3) Old/ This document does not give any recommendations for the use of algorithms, it only gives implementation recommendations for implementations./ New / This document does not give any recommendations for the use of algorithms, it only gives implementation recommendations regarding implementations./ #3 section 3.1, p. 6 , paragraph 2, starting with “ENCR_CHACHA20_POLY1305” Please expand the abbreviation CRFG. I believe this this is the first use of the abbreviation. #4 section 3.4, p 9-10, several paragraphs in here did not provide the final status 4.a p9, last paragraph on page old/ Group 14 or 2048-bit MODP Group is raised from SHOULD+ in RFC4307 as a replacement for 1024-bit MODP Group. / new/ Group 14 or 2048-bit MODP Group is raised from SHOULD+ in RFC4307 to MUST as a replacement for 1024-bit MODP Group. / 4.b p. 9, first paragraph on page, line 1 Old/ Group 19 or 256-bit random ECP group was not specified in RFC4307, as this group were not defined at that time. Group 19 is widely implemented and considered secure./ New / Group 19 or 256-bit random ECP group was not specified in RFC4307, as this group were not defined at that time. Group 19 is widely implemented and considered secure so Group 19’s status is SHOULD. 4.c p.9, paragraph 4, line Old/ Group 1 or 768-bit MODP Group was not mentioned in RFC4307 and so its status was MAY. It can be broken within hours using cheap of-the- shelves hardware. It provides no security whatsoever./ New/ Group 1 or 768-bit MODP Group was not mentioned in RFC4307 and so its status was MAY. It can be broken within hours using cheap of-the- shelves hardware. It provides no security whatsoever. Therefore, its current stsatus is MUST not. #5 section 4.1, p 12, paragraph 2-4: Final status not indicatd 5.a: paragraph 2 Old/ Shared Key Message Integrity Code is widely deployed and mandatory to implement in the IKEv2 in the RFC7296./ New:/ Shared Key Message Integrity Code is widely deployed and mandatory to implement in the IKEv2 in the RFC7296. The status is MUST. / 5.b paragraph 3 Old/ ECDSA based Authentication Methods are also expected to be downgraded as it does not provide hash function agility. Instead, ECDSA (like RSA) is expected to be performed using the generic Digital Signature method. / New/ ECDSA based Authentication Methods are also expected to be downgraded as it does not provide hash function agility. Instead, ECDSA (like RSA) is expected to be performed using the generic Digital Signature method. ECADSA-based Authentication Methods status is “SHOULD”. / 5.c. paragraph 4 Old:/ DSS Digital Signature is bound to SHA-1 and has the same level of security as 1024-bit RSA. It is expected to be downgraded to MUST NOT in the future./ New/ DSS Digital Signature is bound to SHA-1 and has the same level of security as 1024-bit RSA. It is currently at SHOULD NOT, but it is expected to be downgraded to MUST NOT in the future./ 5.d paragraph 5 Old/ Digital Signature [RFC7427] is expected to be promoted as it provides hash function, signature format and algorithm agility./ New/ Digital Signature [RFC7427] is expected to be promoted as it provides hash function, signature format and algorithm agility. Its current status is SHOULD.
draft-ietf-pce-stateful-pce
In 10.1, some references seem to be needed to say how to do that authentication and encryption. IIUC, that's a work in progress, or is that right? If so, when's it likely to be done and usable?
Minor comment: The U flag in the STATEFUL-PCE-CAPABILITY TLV is probably not necessary as the presents of this TVL already indicates that updates are supported; however not an issue.
Joel Halpern's Gen-ART review caused some discussion, which probably should be reflected in the final document.
Below is Lionel's OPS DIR review. I've pointed out some "issues" that might not be real issues for people involved in PCE but that could be at least clarified for readers of this document. Detailed comments are provided below. Regards, Lionel ******************** 2. Terminology This document uses the following terms defined in [RFC5440]: PCC, PCE, PCEP Peer, PCEP Speaker. This document uses the following terms defined in [RFC4655]: TED. This document uses the following terms defined in [RFC3031]: LSP. This document uses the following terms defined in [I-D.ietf-pce-stateful-pce-app]: Stateful PCE, Passive Stateful PCE, Active Stateful PCE, Delegation, LSP State Database. [LM] I didn't find a clear definition of the LSP state, except through the definition of the LSP State database in ietf-pce-stateful-pce-app, i.e. The second is the LSP State Database (LSP-DB), in which a PCE stores attributes of all active LSPs in the network, such as their paths through the network, bandwidth/resource usage, switching types and LSP constraints. As this document heavily relies on this LSP state concept, it could be useful to (re-)define it in this document or to find a correct reference for it. 3.2. Objectives The objectives for the protocol extensions to support stateful PCE described in this document are as follows: [...] o Allow a PCC to delegate control of its LSPs to an active stateful PCE such that a given LSP is under the control of a single PCE at any given time. A PCC may revoke this delegation at any time during the lifetime of the LSP. If LSP delegation is revoked while the PCEP session is up, the PCC MUST notify the PCE about the revocation. A PCE may return an LSP delegation at any point during the lifetime of the PCEP session. [LM] I'm assuming that the PCE returning the delegation has also to notify the PCC. If so, maybe: "the If LSP delegation is returned by the PCE while the PCEP session is up, the PCE MUST notify the PCE about the revocation." [LM] the bullet point could be then splitted into two bullets, one for PCC, one for PCE. 5.4. Capability Advertisement During PCEP Initialization Phase, PCEP Speakers (PCE or PCC) advertise their support of stateful PCEP extensions. A PCEP Speaker includes the "Stateful PCE Capability" TLV, described in Section 7.1.1, in the OPEN Object to advertise its support for PCEP stateful extensions. The Stateful Capability TLV includes the 'LSP Update' Flag that indicates whether the PCEP Speaker supports LSP parameter updates. The presence of the Stateful PCE Capability TLV in PCC's OPEN Object indicates that the PCC is willing to send LSP State Reports whenever LSP parameters or operational status changes. The presence of the Stateful PCE Capability TLV in PCE's OPEN message indicates that the PCE is interested in receiving LSP State Reports whenever LSP parameters or operational status changes. [LM] is it "willing/interested for" or just a capability indication? It is not the same thing from a procedure point of view. The PCEP extensions for stateful PCEs MUST NOT be used if one or both PCEP Speakers have not included the Stateful PCE Capability TLV in their respective OPEN message. If the PCEP Speaker on the PCC supports the extensions of this draft but did not advertise this capability, then upon receipt of PCUpd message from the PCE, it MUST generate a PCErr with error-type 19 (Invalid Operation), error-value 2 (Attempted LSP Update Request if the stateful PCE capability was not advertised)(see Section 8.5) and it SHOULD terminate the PCEP session. If the PCEP Speaker on the PCE supports the extensions of this draft but did not advertise this capability, then upon receipt of a PCRpt message from the PCC, it MUST generate a PCErr with error- type 19 (Invalid Operation), error-value 5 (Attempted LSP State Report if active stateful PCE capability was not advertised) (see Section 8.5) and it SHOULD terminate the PCEP session. [LM] why the recommendation for closing the session if an explicit error is sent back? The session could remain open i.e. except stateful PCEP extensions,everything else would be fine. If the session termination is the right thing to do, as we are in a clear error case (as the PCEP speaker should not send the report or the update), the SHOULD should probably be a MUST hee. [LM] Is there any reason to use a specific error in such a case? The PCE could just behave as a PCE not supporting the feature. Why is it important for the supporting PCEP speaker to make the difference? The generic behavior described in RFC5440 is not enough? [LM] active/passive mode are not advertized in PCEP. s/if active stateful PCE capability was not advertised/if stateful PCE capability was not advertised >From RFC5440: "6.9. Reception of Unknown Messages A PCEP implementation that receives an unrecognized PCEP message MUST send a PCErr message with Error-value=2 (capability not supported). If a PCC/PCE receives unrecognized messages at a rate equal or greater than MAX-UNKNOWN-MESSAGES unknown message requests per minute, the PCC/PCE MUST send a PCEP CLOSE message with close value="Reception of an unacceptable number of unknown PCEP message". A RECOMMENDED value for MAX-UNKNOWN-MESSAGES is 5. The PCC/PCE MUST close the TCP session and MUST NOT send any further PCEP messages on the PCEP session." [LM] If it is the case, the error handling would be the same between a PCEP speaker supporting the feature but not advertizing it and a PCEP speaker not supporting the feature. And it would not be possible possible to use the specific error responses to infer the capability supported by the other node. Note that even if the update capability has not been advertised, a PCE can still accept LSP Status Reports from a PCC and build and maintain an up to date view of the state of the PCC's LSPs. [LM] I don't undersand. Is it not in contradiction with "If the PCEP Speaker on the PCE supports the extensions of this draft but did not advertise this capability, then upon receipt of a PCRpt message from the PCC, it MUST generate a PCErr with error- type 19 (Invalid Operation), error-value 5 (Attempted LSP State Report if active stateful PCE capability was not advertised) (see Section 8.5) and it SHOULD terminate the PCEP session." Or does it mean that there is another way than PCRpt message for the PCC to send LSP status reports to the PCE? [LM] In this section, it is not described how non-supporting PCEP speaker will hanlded the new TLV. It could be said that unrecognized TLVs will be ignored (as per RFC5440) and OPEN messages will be handled as per RFC5440 (if the comment above is accepted). [LM] Would it be useful to discover (using another TLV) whether the PCE is an active/passive stateful PCE, as in IGP-based capabilities discovery mechanism? 5.5. IGP Extensions for Stateful PCE Capabilities Advertisement When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs are either LSRs or servers also participating in the IGP, an effective mechanism for PCE discovery within an IGP routing domain consists of utilizing IGP advertisements. [...] Note that while active and passive stateful PCE capabilities may be advertised during discovery, PCEP Speakers that wish to use stateful PCEP MUST negotiate stateful PCEP capabilities during PCEP session setup, as specified in the current document. A PCC MAY initiate stateful PCEP capability negotiation at PCEP session setup even if it did not receive any IGP PCE capability advertisements. [LM] As said above, an as stated in section 5.4: "The PCEP extensions for stateful PCEs MUST NOT be used if one or both PCEP Speakers have not included the Stateful PCE Capability TLV in their respective OPEN message." What is the real added-value of this IGP-based mechanism? Only to be able to identify active PCE/passive PCE mode? 5.6. State Synchronization [LM] "State" could be misleading. "LSP State Sync" would be more approriate/accurate I think. The purpose of State Synchronization is to provide a checkpoint-in- time state replica of a PCC's LSP state in a PCE. State Synchronization is performed immediately after the Initialization phase ([RFC5440]). During State Synchronization, a PCC first takes a snapshot of the state of its LSPs state, then sends the snapshot to a PCE in a sequence of LSP State Reports. Each LSP State Report sent during State Synchronization has the SYNC Flag in the LSP Object set to 1. The set of LSPs for which state is synchronized with a PCE is determined by advertised stateful PCEP capabilities and PCC's local configuration (see more details in Section 9.1). [LM] It seems that : "The set of LSPs for which state is synchronized" should be: "The set of LSPs for which state is to be synchronized" [LM] I don't see how the "advertised stateful PCEP capabilities" have an effect on the set of LSP to synchronize. The capabilities adv is only used to discover stateful PCE capabilities and see if the related PCEP extensions can be used. The identification of the LSPs to synchronize seems to be only based on policies configured in the PCC. The end of synchronization marker is a PCRpt message with the SYNC Flag set to 0 for an LSP Object with PLSP-ID equal to the reserved value 0 (see Section 7.3). In this case, the LSP Object SHOULD NOT include the SYMBOLIC-PATH-NAME TLV and SHOULD include the LSP- IDENTIFIERS TLV with the special value of all zeroes. The PCRpt message MUST include an empty ERO as its intended path and SHOULD NOT include the optional RRO object for its actual path. [LM] What is the reason for the use of "SHOULD" here, instead of "MUST"? If the PCC has no state to synchronize, it SHOULD only send the end of synchronization marker. [LM] Is it when there is no active LSP? If it is, it could be useful to clarify it. And it is maybe not so related to the text just before. It could be clarified in a separate paragraph. A PCE SHOULD NOT send PCUpd messages to a PCC before State Synchronization is complete. A PCC SHOULD NOT send PCReq messages to a PCE before State Synchronization is complete. This is to allow the PCE to get the best possible view of the network before it starts computing new paths. [LM] it is obviously assumed that this requirement is true for PCC/PCE explicitly advertizing support of stateful PCE capability. If the PCC encounters a problem which prevents it from completing the state transfer, it MUST send a PCErr message with error-type 20 (LSP State Synchronization Error) and error-value 5 (indicating an internal PCC error) to the PCE and terminate the session. [LM] s/state transfer/LSP state synchornization 5.7.1. Delegating an LSP A PCC delegates an LSP to a PCE by setting the Delegate flag in LSP State Report to 1. If the PCE does not accept the LSP Delegation, it MUST immediately respond with an empty LSP Update Request which has the Delegate flag set to 0. If the PCE accepts the LSP Delegation, it MUST set the Delegate flag to 1 when it sends an LSP Update Request for the delegated LSP (note that this may occur at a later time). The PCE MAY also immediately acknowledge a delegation by sending an empty LSP Update Request which has the Delegate flag set to 1. [LM] if the delegation is not aceepted by the PCE, I assume that the PCC should not set the Delegate flag in subsequent LSP state report. If it is, this could be clarified somewhere in this section. [..] Note that for an LSP to remain delegated to a PCE, the PCC MUST set the Delegate flag to 1 on each LSP Status Report sent to the PCE. [LM] s/each LSP Status Report/each LSP State Report for this LSP. 5.7.2.1. Explicit Revocation When a PCC decides that a PCE is no longer permitted to modify an LSP, it revokes that LSP's delegation to the PCE. A PCC may revoke an LSP delegation at any time during the LSP's life time. A PCC revoking an LSP delegation MAY immediately clear the LSP state provided by the PCE, but to avoid traffic loss, it SHOULD do so in a make-before-break fashion. [LM] After PCE delegation revocation, is there really a requirement for LSP state clean-up? The revocation is used to remove the authorization of LSP state update to the PCE but I don't see why the PCC would clear LSP state after revocation. The LSP state can be updated using operator-defined default parameters, right? If the PCC has received but not yet acted on PCUpd messages from the PCE for the LSP whose delegation is being revoked, then it SHOULD ignore these PCUpd messages when processing the message queue. All effects of all messages for which processing started before the revocation took place MUST be allowed to complete and the result MUST be given the same treatment as any LSP that had been previously delegated to the PCE (e.g. the state MAY be immediately cleared). [LM] If I correctly understood the text above, after revocation of the PCE delegation, - any PCUpd should be rejected and not ignored - the LSP state(s) that was delegated to the PCE cannot be changed until all the messages in the message queue have been processed. If I'm correct, the text above could be clarified. Any further PCUpd messages from the PCE are handled according to the PCUpd procedures described in this document. [LM] Not understood. Further PCUpd "will result in the PCC sending a PCErr message" as said after the figure. 5.7.2.2. Revocation on Redelegation Timeout When a PCC's PCEP session with a PCE terminates unexpectedly, the PCC MUST wait the time interval specified in Redelegation Timeout Interval before revoking LSP delegations to that PCE and attempting to redelegate LSPs to an alternate PCE. If a PCEP session with the original PCE can be reestablished before the Redelegation Timeout Interval timer expires, LSP delegations to the PCE remain intact. [LM] In case of PCEP session interruption, is there a requirement for the PCE to update delegated LSP states in order to ensure the synchronization between states in the PCE and in the PCC? Likewise, when a PCC's PCEP session with a PCE terminates unexpectedly, the PCC MUST wait for the State Timeout Interval before flushing any LSP state associated with that PCE. [LM] it should be clarified that the "flushing" applies only if there is no other PCE. Otherwise, see section 5.7.4 Note that the State Timeout Interval timer may expire before the PCC has redelegated the LSPs to another PCE, for example if a PCC is not connected to any active stateful PCE or if no connected active stateful PCE accepts the delegation. [LM] Not sure to understand. Is it "if a PCC is not connected to any OTHER active stateful PCE or if no OTHER connected active stateful PCE accepts the delegation? In this case, the PCC MUST flush any LSP state set by the PCE upon expiration of the State Timeout Interval and revert to operator-defined default parameters or behaviors. This operation SHOULD be done in a make-before-break fashion. [LM] I think it is important to make the distinction between PCC with only one PCE and PCC with N PCE. The "Note that" could be put in a separate section. The State Timeout Interval MUST be greater than or equal to the Redelegation Timeout Interval and MAY be set to infinity (meaning that until the PCC specifically takes action to change the parameters set by the PCE, they will remain intact). [LM] reading "the State Timeout Interval timer may expire before the PCC has redelegated the LSPs to another PCE" could be understood as STI timer < RTI timer. And here, it is stated STI timer >= RTI timer. Depending on the clarification on the previous comment, this text could be also clarified (or not) 5.7.3. Returning a Delegation In order to keep a delegation, a PCE MUST set the Delegate flag to 1 on each LSP Update Request sent to the PCC. A PCE that no longer wishes to update an LSP's parameters SHOULD return the LSP delegation back to the PCC by sending an empty LSP Update Request which has the Delegate flag set to 0. If a PCC receives an LSP Update Request with the Delegate flag set to 0 (whether the LSP Update Request is empty or not), it MUST treat this as a delegation return. +-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ | | |---PCRpt, Delegate=1--->| LSP delegated | . | | . | | . | |<--PCUpd, Delegate=0----| Delegation returned | | |---PCRpt, Delegate=0--->| No delegation for LSP | | Figure 6: Returning a Delegation If a PCC cannot delegate an LSP to a PCE (for example, if a PCC is not connected to any active stateful PCE or if no connected active stateful PCE accepts the delegation), the LSP delegation on the PCC will time out within a configurable Redelegation Timeout Interval and the PCC MUST flush any LSP state set by a PCE at the expiration of the State Timeout Interval. [LM] same comment: is it "for example, if a PCC is not connected to any OTHER active stateful PCE or if no OTHER connected active stateful PCE accepts the delegation"? [LM] "the PCC MUST flush any LSP state set" should be completed by "and revert to operator-defined default parameters or behaviors", right? 5.7.5. Redelegation on PCE Failure [...] If the PCE crashes but recovers within the Redelegation Timeout, both the delegation state and the LSP state are kept intact. [LM] "Recover" here seems to be associated with the PCEP session (as linked to the Redelegation Timeout), not with the LSP states maintained by the PCE. [LM] How can the PCC be ensured that the PCE has not been impacted by the stop/restart and that LSP states are intact? Is there any need for a sanity check? If the PCE crashes but does not recover within the Redelegation Timeout, the delegation state is returned to the PCC. If the PCC can redelegate the LSPs to another PCE, and that PCE accepts the delegations, there will be no change in LSP state. If the PCC cannot redelegate the LSPs to another PCE, then upon expiration of the State Timeout Interval, the state set by the PCE is flushed, which may cause change in the LSP state. [LM] the last sentence is difficult to understand. How to understand "flush the state MAY cause change in the LSP state"? It would like talking about two different states in the PCC. [LM] about "flushed", should we add "and revert to operator-defined default parameters or behaviors"? [...] If there is a standby PCE, the Redelegation Timeout may be set to 0 through policy on the PCC, causing the LSPs to be redelegated immediately to the PCC, which can delegate them immediately to the standby PCE. Assuming the State Timeout Interval is greater than the Redelegation Timeout, and assuming the standby PCE takes similar decisions as the failed PCE, the LSP state will be kept intact. [LM] the first "assuming" is not an assumption but a requirement, according to "The State Timeout Interval MUST be greater than or equal to the Redelegation Timeout Interval" 5.8.1. Passive Stateful PCE Path Computation Request/Response +-+-+ +-+-+ |PCC| |PCE| +-+-+ +-+-+ | | 1) Path computation |----- PCReq message --->| request sent to | |2) Path computation PCE | | request received, | | path computed | | |<---- PCRep message ----|3) Computed paths | (Positive reply) | sent to the PCC | (Negative reply) | 4) LSP Status change| | event | | | | 5) LSP Status Report|----- PCRpt message --->| sent to all | . | stateful PCEs | . | | . | 6) Repeat for each |----- PCRpt message --->| LSP status change| | | | Figure 7: Passive Stateful PCE Path Computation Request/Response [LM] in the figure, please use "state" instead of "status" 7.1. OPEN Object This document defines one new optional TLVs for use in the OPEN Object. s/one new optional TLVs/one new optional TLV 7.2. SRP Object The SRP (Stateful PCE Request Parameters) object MUST be carried within PCUpd messages and MAY be carried within PCRpt and PCErr messages. The SRP object is used to correlate between update requests sent by the PCE and the error reports and state reports sent by the PCC. [LM] Should we add the following text at the end of the section? "Optional TLVs may be included within the SRP object body. The specification of such TLVs is outside the scope of this document." 7.3. LSP Object [...] TLVs that may be included in the LSP Object are described in the following sections. [LM] I think that it is possible to add extra optional TLV, not defined in this document. This should be clarified if I'm correct.
1. Maybe it's just me, but what is the Symbolic Path Name used for? There is a mapping to the PLSP-ID, and the required lifetime may be different, but I don't see where the use is explained (or why it's even needed). Also, is there any expectation to the length or character set? Given that the "symbolic path name MAY be specified by an operator in a PCC's configuration", I'm guessing it has to be something than can be printed...but there are no specifics. 2. In 9.2: "PCEP session configuration and information in the PCEP MIB module SHOULD be extended to include advertised stateful capabilities...". Ok, but I think the "SHOULD" is out of place. s/SHOULD/should
draft-ietf-dime-load
- From the shepherd writeup: The document would benefit from a review by AAA Doctors. I wonder if it happened? - OLD: The DIME working group explicitly chose not to fulfill these requirements in DOIC due to several reasons. NEW: The DIME working group explicitly chose not to fulfill these requirements when publishing DOIC [RFC7683] due to several reasons. - pay attention to the consistency of Load versus load trough out the document.
Since DIME doesn't have end-to-end security, shouldn't the security considerations section mention that as well? It seems to fit the security considerations and would serve as a reminder of this problem.
More or less editorial comments: 1) These two MUSTs are actually hard to "ensure" and should probably be SHOULDs or lower case musts: sec 6.1.1: "A Diameter endpoint that supports the Diameter Load mechanism MUST include a Load report of type HOST in sufficient answer messages to ensure that all consumers of the load information receive timely updates." sec 6.1.2: "A Diameter Agent that supports the Diameter Load mechanism MUST include a PEER Load report in sufficient answer messages to ensure that all users of the load information receive timely updates." 2) This part also seems hard to realize (in sections 6.1.1. and 6.1.2): "The LOAD value should be calculated in a way that reflects the available load independently of the weight of each server, in order to accurately compare LOAD values from different nodes. Any specific LOAD value needs to identify the same amount of available capacity, regardless the Diameter node that calculates the value. The mechanism used to calculate the LOAD value that fulfills this requirement is an implementation decision." 3) I don't think you can require this for all diameter nodes (as they might not implement this extension): "A Diameter node MUST be prepared to process Load reports of type HOST and of type PEER" Just remove the sentence or at least don't use normative language. Side note: This MUST as well as the ones above are like saying "A node that implements/complies to this spec MUST implement this spec". It not really necessary to say this.
consider reviewing the opsdir reviewers nits.
draft-ietf-dime-agent-overload
While I am not a co-author per se, the author is an immediate team-mate.
(Resending because I forgot one more high-level comment; see at the bottom.) One rather important comment: While the security considerations section describes a possible attack, it does not say anything about how to handle this attack and the actually impact this attack might have. Please add more text! And then some mostly editorial high level comments: All in all, I had a rather hard time reading this document because it seems on the one hand sightly over-specified and over structured, while not giving very concrete guidance in some cases. E.g. in section 5.2.5; "In the case that the OCS entry validity duration expires or has a validity duration of zero ("0"), meaning that if the reporting node has explicitly signaled the end of the overload condition then abatement associated with the OCS entry MUST be ended in a controlled fashion." I don't think normative language is needed here because there is no impact of interoperation. But then is does't explain what "in a controlled fashion means". So I wouldn't even know how to implement that MUST correctly. Another example in section 4: " In this scenario, when doing abatement on the PEER report, the reacting node SHOULD take into consideration the number of messages already throttled by the handling of the HOST/ REALM report abatement." How to take that into consideration? And why is this normative? Or here in section 5.2.3: "When a reacting node receives an OC-OLR AVP with a report type of peer it MUST determine if the report was generated by the Diameter peer from which the report was received. If a reacting node receives an OC-OLR AVP of type peer and the SourceID matches the DiameterIdentity of the Diameter peer from which the response message was received then the report was generated by a Diameter peer." Why don't you just say the following: "When a reacting node receives an OC-OLR AVP with a report type of peer it MUST determine that the SourceID matches the DiameterIdentity of the Diameter peer from which the response message was received." Also the indentation used is sometimes confusing. In some cases you should probably really use real listings with bullet points. Please also double-check all normative language: as indicated above there are some cases where the normative language is probably not really needed and there are other cases where an additional upper letter MUST or SHOULD would make things clearer.
Below is the OPS DIR review by Will. ** Editorial ** *Section 2, page 4 > A RFC6733 Diameter Client, an RFC6733 Diameter Server, and RFC6733 > Diameter Agent. s/ RFC6733/ [RFC6733] Similar changes should also be made in this section to get consistent with section 1 and the last sentence in section 2(therein you were using [RFC6733]). * Section 3.1.1, page 4: > +-+ +-+ +-+ > |c|----|a|----|s| > +-+ +-+ +-+ Though I can easily guess what does “c, a, s” mean here, I still suggest to put full words or at least add a sentence below the figure to explain. The same issue should be fixed in all the figures below in entire section 3. * Section 3.1.2, page 6: > In the case where one of the agents in the above scenario becomes > overloaded s/ scenario becomes/ scenarios become If I understand correctly , here you were referring to two scenarios above? > When the client has an active and a standby connection to the two > agents then an alternative strategy for responding to an overload > report from an agent is to change to standby connection to active and > route all traffic through the new active connection. I would suggest to split this sentence in case of misunderstanding. * Section 3.1.3, page 7: > Handling of overload of one or both of agents a11 or a12 in this case > is equivalent to that discussed in section 2.2. Tried hard to find section 2.2, but there is no such section. * Section 5.1.1, page 8: > When sending a Diameter request a DOIC node that supports the > OC_PEER_REPORT feature MUST include in the OC-Supported-Features AVP > an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set. Full name of AVP should be put into terminology.
draft-ietf-pce-stateful-sync-optimizations
I generally agree with the secdir review. TCP/AO is sadly fictional, so please don't let's pretend it's usable to help here. Just recommend TLS. (And add BCP195 too please.)
I only had time to skim this draft, but have no objections. Thanks for your work on it.
(1) The Speaker Entity Identifier concerns me a lot because of the spoofing vector it introduces, and because I don't think the uniqueness is strongly specified. I understand that the risk of spoofing is limited to the State Timeout Interval, but that is a long time: at least 30 sec by default! It looks like the main use case is to avoid state synchronization after an IP address change -- are there other? (2) By making TCP-AO/TLS "RECOMMENDED", this document is not in line with RFC5440, where only TCP-MD5 is mandatory. I don't think the intent of this document is to Update RFC5440, is it? Also, why would the recommendations for this extension be different than those in draft-ietf-pce-stateful-pce (which doesn't go beyond what RFC5440 mentions)? If you do keep the current recommendation, then draft-ietf-pce-pceps should be a Normative reference.
draft-ietf-pce-inter-layer-ext
The "enhanced" security considerations proposed in response to Mirja's comments resolve my discuss. I am clearing on the assumption it makes it into the draft. I've moved my discuss point into the comments for now: <old-discuss> If I am reading things correctly, the security considerations just say the extensions in this draft may raise new security considerations, but doesn't say anything about what they might be. That's an incomplete analysis. What new considerations actually (not "may") exist? What potential attacks may be enabled by these extensions, if any? Are there things people can do to mitigate them? </old-discuss>
Minor comments: 1) I guess the I flag in the INTER-LAYER Object is actually not needed as the present of the INTER-LAYER Object already indicates that inter-layer information is requested, but that is not an issue. 2) Is the INTER-LAYER Object Flags registry really needed, given the limited amount of flag space??? 3) Security Consideration: "Inter-layer traffic engineering with PCE may raise new security issues when PCE-PCE communication is done between different layer networks for inter-layer path computation." This text is not very helpful as this section is meant to be used to document these new issues.
The typo raised in the Gen-Art review should be corrected.
draft-ietf-lmap-yang
This draft does not specify a bootstrapping process (see RFC 7594 5.1. Bootstrapping Process) and says: "Pre-Configuration Information: This is not modeled explicitly since bootstrapping information is outside the scope of this data model." So when and where and how will this be specified?
Also it is not clear when and how to perform configuration actions. To be a fully function protocol more guidance is needed. Not sure if that is even the intention of this document but I don't see any other documents that serves this purpose in the lmap queue. (And the milesstones are not up to date and don't indicate with document maps to which milestone.)
I only skimmed the document, but I have no objections.
Figure 1: There is a typo (actually four typos) in the yang module name ietf-lmap-comman.yang should be ietf-lmap-common.yang instead
- No objection to the publication, but the following phrasing puzzles me. It aims to be consistent with the LMAP Information Model [I-D.ietf-lmap-information-model]. Actually, the data model is based on information model, right? From the charter: 5. The Report protocol and the associated data model: The definition of how the Report is delivered from a MA to a Collector; this includes a Data Model consistent with the Information Model plus a transport protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). This is reason why the information model is standard track in the charter. Therefore the information model must be a normative reference, right? - one question about the typedefs naming. It would nice to be able to reuse YANG constructs, typedefs being of them We created http://www.yangcatalog.org/yang-search/yang-search.php with that goal in mind. => insert "identifier" => select typedef Some of the typedefs are so generically named in LMAP YANG module: identifier, tag, cycle-number, wildcard, etc. Do you expect YANG designers to reuse them outside of LMAP? Some of them, I guess so Should the other ones be renamed with LMAP in mind. Ex: lmap-identifier? In other words, are all the ietf-lmap-common.yang typedef common? Editorial: - figure 1 OLD: ietf-lmap-comman.yang NEW: ietf-lmap-common.yang
The security considerations looks good, but can't YANG also be accessed via RESTCONF? What considerations are needed for that? I thunk we went through this for I2RS, do considerations for RESTCONF apply to this YANG module?
draft-ietf-lmap-information-model
Why is this document Standards Track? I think it should be informational! Minor comments/questions: - It's not really explained what tags are (see ma-report-result-tags) ? And what's the differents to options (ma-report-result-options)? - Is it correct that an ma-report-table-obj can cover multiple ma-report-table-functions? Examples would be good here! - Sec 3.7.: "There is no mechanism to prioritise one schedule over another or to mutex scheduled tasks." Why is that? Was this discussed? I would guess that would be important to have! - Wouldn't it makes sense to discuss the common objects first? - The regristry concept is rather unclear to me as it suddently shows up in section 3.10. Especially what's a role in this context (ma-registry-role)? Example?
I concur with Russ's comment in his GenArt review that the credentials/certificates described in section 3.1 warrant discussion in the security considerations section.
I only skimmed the document. ma-log-description: A human readable description of the event. As per Section 4 of BCP 18 <https://tools.ietf.org/html/bcp18>, human readable text should be associated with language tags. You should consider adding this functionality to the information model.
Russ's comment/question about the credentials is a good one. It is fine to have different arrangements for different situations, but Russ’s question was really not about that but whether the CA information mentioned earlier is a part of a specific part of the information model (ma-credentials). I think that deserves clarification.
In the security considerations section, I see the following text: These mechanisms are important to ensure that the MA cannot be hijacked, for example to participate in a distributed denial of service attack. Wouldn't using the systems or the collected data for network recon (or other attacks) be a more important consideration to be listed than DDoS?
draft-ietf-grow-mrt-add-paths
The abstract says this draft updates MRT. Does it update RFC 6396? Or maybe the abstract should this say "extends"?
draft-ietf-ipsecme-rfc7321bis
I'm balloting "Yes", but I have a few minor comments/questions: - Abtstract: "This document obsoletes RFC 7321 on the cryptographic recommendations only." I'm not sure what that means. Does the reader of this still need to read 7321? If so, is "obsoletes" the correct relation? -3: I wonder why "... is not to be used..." is not "... MUST NOT be used...". But the section goes on to say if you do it anyway, you MUST NOT use certain cryptosuites. So, does "... is not to be used..." mean "SHOULD NOT"? Or is this one of those "MUST NOT BUT WE KNOW YOU WILL" sort of requirements? - Table in section 6: I'm boggled by the first entry being labeled "MUST/MUST NOT". I don't see anything in the text to explain the "MUST" part--did I miss something?
"Interoperability with IoT" doesn't parse when I read it -- maybe you mean "for IoT devices to interoperate" or something like that?
As discussed based on the OPS DIR review: Hi Paul, To avoid any future questions, are your 3 justifications below mentioned in the draft? Regards, Benoit > On 03/13/2017 07:17 AM, Sheng Jiang wrote: > > Hello Sheng, > > thanks for your review! > >> Comparing with RFC 7321, this document uses different names for algorithms. Although it looks consistent, it may reduce readability a little. The below items, I would like to double check for consistent. >> >> >> >> 3DES ?= TripleDES-CBC (old) >> >> DES ?= DES-CBC (old) >> >> AES_XCBC_96 ?= AES-XCBC-MAC-96 (old) > e actually changed all names to match the actual IANA IKEv2 entries at http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml > >> There are a few new algorithms mentioned, without any description or analysis. Additional explanation should be needed. >> >> >> DES_IV64 >> >> DES_IV32 >> >> 3IDEA > Those are old reserved entries that have no implementation and therefor actually have no RFC we can point to. Which is also why we made > it very clear these are MUST NOT. > >> I actually have more concerns regarding to the below algorithm that is mentioned in RFC7321, but not in this document. Does it create a new hole? >> >> >> AES-CTR [RFC3686] > It was mentioned in 7321 because it went from SHOULD to MAY. > > It is not mentioned in 7321bis because it is still at MAY, and we do not list any algorithms in MAY. > > I hope this clarifies your questions, > > Paul
- I agree with Christian's secdir review [1] that this doesn't seem justified (at least on it's face): " If manual keying is used anyway, ENCR_AES_CBC MUST be used, and ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT be used as these algorithms require IKE. " Can you explain the reasoning that lead the WG to say that? - ENCR_NULL IMO ought be MUST NOT - did the WG discuss that explicitly? If so, can you provide a pointer to the archive? If not, does it still have to be a MUST? I do wonder who wants to use AH via NAT but cannot, which seems to be the justification. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg07262.html
draft-ietf-tls-rfc4492bis
I would like to vote Yes on this document, but there are some minor issues with this document which prevent me from doing so: 0) There is some general awkwardness in text talking about allowed points formats, considering that only uncompressed form is now allowed. I don't have recommendations about improving text, other than the following: If no future formats are expected, it feels almost better to recommend against inclusion of the Point formats extension, as lack of it means uncompressed format anyway. 1) In Section 2.3, last paragraph: Does this paragraph apply only to 2.3 or does it also apply to 2.1 and 2.2? If the latter, then it needs to be moved to section 2. 2) In Section 6: Server implementations SHOULD support all of the following cipher suites, and client implementations SHOULD support at least one of them: o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 GCM ciphers are not listed in the table earlier in the same section. They are defined in RFC 5289. This document doesn't have any reference to RFC 5289 and GCM ciphers are not discussed anywhere else in the document.
Thanks for your work on this draft. I just have one question: In section 5.10, I see the following text: The default hash function is SHA-1 [FIPS.180-2], and sha_size (see Section 5.4 and Section 5.8) is 20. However, an alternative hash function, such as one of the new SHA hash functions specified in FIPS 180-2 [FIPS.180-2], SHOULD be used instead. Why are you setting the default to SHA-1 and then recommending that something else should be used? Why not just start with a different SHA hash function as the default or at least for TLS 1.2? I do see the prior text about TLS 1.0 and 1.1 using MD5 and SHA-1, but most have recommended to go right to TLS 1.2 with the SSLv3 deprecation. As such, I'm not clear on why the SHA-1 default.
draft-leiba-rfc2119-update
I might be stating the obvious, but would this require tool changes, such as idnits?
draft-bchv-rfc6890bis
A document that obsoletes an existing RFC needs to contain section describing changes since. I haven't found this. (Ben and Benoit are effectively explained this in more details.)
I share the concern raided by Suresh and Benoit about the difficulty in reviewing this draft without a summary of changes. There were similar concerns raised by the GenART and RTGDIR reviewers.
I find myself in a situation in which I have no clue how to review this document. - Should we compare information with https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml and https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml ? - Should we do a diff with RFC6890? - Something else? All the information I can read is: This memo reiterates the assignments made to the IPv4 and IPv6 Special-Purpose Address Registries and augments the fields contained within the registries in order to address the confusion raised by the definition of "global". Should I spend my time trying to determine what has been augmented. This really calls for a "what has changed since RFC 6890" section My ballot status: No record.
Please take a look at the RTGDir review from Dan Frost: https://mailarchive.ietf.org/arch/msg/rtg-dir/o0wVKmUiLodDQbcaDPeRQ0hLpFM
status-change-uplifting-rfc5289-to-ps
This seems like a fine thing to do. I am curious about whether there's an intention to uplift other Informational cipher suites RFCs to proposed standard - I don't know the topology here, but I do see that we've published Informational RFCs with "cipher suite" in the title, as recently as 2014 (per https://datatracker.ietf.org/doc/search/?name=Cipher+suit&rfcs=on). But I'm a No Objection, no matter what the answer is.
draft-ietf-mpls-tp-temporal-hitless-psm
OPS DIR review from Jon Mitchell: Document is Ready with Nits. I share the concern that it's not totally clear upfront this is a requirements versus solution document. There is also not much in the way of requirements of notification or how to signal back to the operator that a fault has occurred, but this may be OK if whatever solution would meet the requirements of this draft will include such text or rely on existing mechanisms discussed in RFC6371.
I do not see the value of this document as an RFC - particularly absent any work on a solution after 5 years.
I don't see a value in publishing this document in the RFC series. Btw. the shepherd write up still says this doc is standards track. Minor comments: - The classification into M(andatory) and O(ptional) is not consistent with the use of MUST and SHOULD. - The first sentence in the intro should use a lower case 'must'. - Sections 2.2 and 5. could be removed.
draft-ietf-httpbis-http2-encryption
I'm balloting "yes", but I have a few minor comments: - Abstract: I agree with the GenART review that the limitations should be mentioned in the abstract, or at least early in the document. - Note to readers: Will this stay in the RFC? - Introduction: What is the nature of the experiment? Is there an expectation to promote it to standards track in the future? Even if the answer is "We need to get implementation/deployment experience", it's helpful to say "out loud".
draft-ietf-bmwg-virtual-net
I have a few mostly editorial comments: - Abstract and Introduction: Missing "the" before "Benchmarking..." -Abstract: Will the paragraph about new version history stay in the RFC? -1: Much of this section, especially the 2nd paragraph, reads like a commercial, or a marketing white paper. I'm not going to put this in the way of publication, but an IETF RFC should generally take a more neutral tone. It's enough to acknowledge that people are doing (or plan to do) NFV. -2: Language of the form of "BMG will consider" will quickly become dated. Consider something to the effect of "At the time of this writing, BMG is considering/plans to consider..." Can you offer a definition or citation for "bare metal"? "Also, benchmarking combinations of physical and virtual devices and functions in a System Under Test.": Sentence fragment. - 4.2, first paragraph, last sentence: Can you offer a citation for the 4x3 matrix? :
A clear and well-written doc - thanks!
Thanks for the well written doc!
draft-ietf-dane-smime
Minor comments: - Point 8 in the shepherd write-up is not addressed and this docuemnt has 2 IPR claims... - Intro: "Thus, the reader must be familiar with RFC 6698 before reading this document." -> That means RFC6698 must be normative.
Agree with Mirja and Alexey's position about the references. At least RFC6698 needs to be normative.
There's a rather icky IPR disclosure that basically says that licensing terms won't be disclosed until they see where the draft is going. The shepherd's review doesn't mention whether the working group discussed that. Since this is experimental, it probably doesn't matter very much right now. I hope that gets some discussion prior to any attempt to promote this work to standards track.
Thank you for this document. I have a small list of comments: 1) You are pointing to Unicode 5.2, which is rather old. You should reference the most recent version. 2) In Section 9.2: NSEC and NSEC3 need references. 3) In Section 11: <pedantic comment alert> All of your references are Informative. This is not correct, as several of the references are needed to implement or understand this specification. It doesn't matter that this document is Experimental, references needed to implement or understand the document still need to be Normative.
draft-hardie-privsec-metadata-insertion
I fully support the publication of this document, however, given this is not an IAB document (anymore), I would recommend to do some more re-wording to rather talk about a design pattern that should be applied in future protocol design work than to give advise about what should not be done. Also I think it would be good to add a little bit more text that further discusses/explains that endpoints may also need a way to detect middlebox insertion/manipulation to provide an incentive to support host-based explicit actions for metadata provisioning.
= Section 5 = "It would not be available at all during this period" -- this seems to be imagining an alternative reality where the forwarded header is not already inserted by proxies, which confused me. I think this first paragraph either needs to be clear that it is imagining an alternative history in which the forwarded header was never inserted by proxies, or it should not include the quoted text above, since at this point one could wait for browsers to be upgraded to support a client-based insertion mechanism while proxies are still inserting the same info. = Section 7 = Is there some citation that could be provided to support the assertion that network-provided location is "often" more coarse than device-provided location? I have been inclined to believe it but it seems like a mildly contentious claim.
Section 3 just has one design pattern, restoration of data, right? Should the heading be design pattern and not design patterns or are you considering data minimization a design pattern too? I don't think so, but wanted to ask for clarity in the document. Section 4 then starts off with a statement: "Avoid this design pattern". I think it would be clearer to reword as, "Avoid the restoration of information design pattern" or make it clear that section 3 is talking about one design pattern (like the introduction). Theres a word left out in section 5, 3rd paragraph "There also tensions with latency of operation." s/There also/There are also/ Section 7, second sentence: s/metadat/metadata I also agree with the SecDir reviewers comments: https://mailarchive.ietf.org/arch/msg/secdir/8buJWINMRQmtN0Ls78yFAPjr3ug The suggested updates don't appear to have made it to this last version. Are changes coming to clarify the text? I can't tell from the end of that thread.
I support this document, but I am not convinced that it will have the desired effect.
draft-mm-wg-effect-encrypt
Why is section 11 in the appendix only? I would see this as an important part of the document because it seems to me that mobile operators are the ones most impacted by encryption.
I would be a 'Yes' because I think this document is very valuable, however, I think it could be structured better to provide more value. The document is rather long and has some redundancy due to the structure: while sections 2.-4. are split based on the type of network operator, sections 5. and 6. are split based on the protocol layer. Further I think section 2 could be further extended because there are more cases to cover, also see (section 3 of) https://tools.ietf.org/html/draft-dolson-plus-middlebox-benefits-03. See for more concrete and mostly editorial comments below: 1) sec 2.1.1: "The definition of a flow will be based on a combination of header fields, often as many as five for 5-tuple flows (including addresses and ports for source and destination, and one additional field such as the DSCP or other priority marking)." Usually the 5th field is the protocol number; I'm not aware of any load balancers that look at DSCP...? 2) sec 2.1.4 seems to cover two different cases: caching and differential treatment 3) sec 2.1.6. should probably be called "Content Filtering" and "Mobility Middlebox Content Filtering" should be an own subsection, as parental filtering is not specific to mobile networks. 4) I don't really understand why sec 2.1.7 "Access and Policy Enforcement" is a subsection of 2.1 "Middlebox Monitoring". Was that on purpose or an error? Actually I don't really understand the structure of section 2 at all. What's the difference between 2.1 and 2.2? I would group section 2.1.1, 2.1.2, and 2.1.3 under Traffic Monitoring and move all other subsections of 2.1 one level up... 5) sec 3 rather describes how encryption is already used and doesn't not really discuss any effects of increased use of encryption. 6) there is quite some overlap between section 2 and 4.1.3. as the problems on monitoring/troubleshoot are the same for enterprise network and other networks; the only difference is that in enterprises TLS interception may be acceptable while it's not for network operators. However, it would still be good to better align these sections. 7) section 6 only describes with information is visible but not how and if this information is used and what would happen if this information would go away. 8) section 7 should be integrated in the introduction because it sets the context for this document and it's not needed to have read the rest of the document to understand this section.
I agree with Ekr's comment concerning the sometimes adversarial relationship between the SP and the user, and the use of the word "need" in several places. -1: Can you elaborate on : "Once OS is used, it allows for an upgrade to authenticated encryption."? I suspect you refer to the 7435 mention that OS may offer an evolution path to authenticated, encrypted communication. But as written, It sounds like it is trying to say OS offers an upgrade option for a particular session. - 2.1.1: I'm not sure I follow the part about encryption that conceals the 5-tuple from a load balancer. The scenarios that spring to mind fall into the "why would anyone do that" category, but I assume that's due to my own lack of imagination. A concrete example might help. -2.1.2, paragraph 2: How is filtering on higher-layer data related to traffic analysis? -2.1.4: This section seems to treat DPI as an end in itself. It's a tool to be used to accomplish certain goals, but if those goals went away, I don't think people would be too worried about the loss of DPI. - 3.1.1: Again, I'm confused by the part about encryption that conceals the 5-tuple in the context of filtering. Is previously untunneled traffic becoming tunneled without the cooperation of hosted service provider or application provider? - 3.1.2:I'm confused by this case. In the ASP case, I would assume the same authority would control at least one application endpoint as controls the network, and therefore should be able to get whatever information they need from that endpoint. Is there some assumption that this is not the case? If so, it would be worth mentioning.
We have a few small nits queued up - the two from idnits Badri Subramanyan's name will be added to the ACKs and Section 2.1.6.2 needs a small typo correction 2. Further contenty may not s/contenty/content/
1) In Sec 2.1.1, it says "(including addresses and ports for source and destination, and one additional field such as the DSCP or other priority marking)." The DSCP field isn't included both because its value can chance based on ECN and because there can be packets in the same flow with different DSCP values (AF11 vs. AF12 vs. AF13). The 5 fields usually included are: IP src/dest, Protocol field, src/dest ports. This is correct in Section 3.1.1 2) Sec 3.1.2 refers to "Secure overlay networks (for example, VXLAN)" which is startling because VXLAN has no security mechanisms in it; it's just an additional header that can encapsulate Ethernet traffic. It's like claiming MPLS is secure because it is layer 2.5. There is some work starting in NVO3 about security extensions to go with the chosen encap (Geneve as a VXLAN replacement) and GUE (a WG draft in intarea) has some security extensions proposed. I think this paragraph needs some rework. An overlay network can be used to provide isolation but this isolation just isn't secure - even more than VLANs don't add real protection for Ethernet traffic (but switches restrict what traffic is duplicated on the network based on VLAN membership on the links).
= Section 2.1.6.2 = "Once the content is encrypted, the Mobile carrier loses the option to redirect the traffic leaving the option to block the customer's request and cause a bad customer experience untill the blocking reason can be conveyed by some other means." If all that is encrypted is the application payload, why does the mobile carrier lose the option of being able to do this based on the 5-tuple? This seems to me to be a false statement, or it is assuming some conditions which need to be made more clear.
Updated COMMENT with some more comments: COMMENT: = General = I agree with Ekr's general comment. = Section 2.1 = "Encryption that conceals or replaces the original IP header" -- Section 1 doesn't give any particular indication that these kinds of techniques are on the rise; are there stats you could include, similar to the web ones that are included? = Section 2.1.2 = I find the co-mingling of traffic analysis for DDoS mitigation and endpoint fingerprinting in this section to be confusing. Are you saying that payload encryption is making both of these harder? If so, is the fact that attackers are having trouble more trouble doing endpoint fingerprinting seen as beneficial, or detrimental? = Section 2.1.3 = "Passive monitoring makes inferences about observed traffic using the maximal information available, and is subject to inaccuracies stemming from incomplete sampling (of packets in a stream) or loss due to monitoring system overload. When encryption conceals more layers in each packet, reliance on pattern inferences and other heuristics grows, and accuracy suffers. For example, the traffic patterns between server and browser are dependent on browser supplier and version, even when the sessions use the same server application (e.g., web e-mail access)." I'm trying to see if I understand what this is saying. Is the idea that at present, in order to measure traffic volumes, traffic is sampled in a particular way based on which browser version is used? So if the entity doing the monitoring cannot determine the browser version of the traffic it is observing, the current model it uses to sample traffic and calculate a measurement becomes non-representative of the traffic it is trying to measure? = Section 2.1.5 = "or worse, they will adopt undesirable security practices in order to gain access to the unencrypted data flows" -- Isn't this a possibility for all of the use cases in Section 2.1, that the loss of the monitoring functionality may induce this behavior? If not, it would be helpful to further explain why this only applies to compression in mobile networks. = Section 2.1.6 = This section seems to cast the rationales behind filtering much more narrowly than they are in reality. In particular, lots of filtering happens for reasons other than law enforcement requests (as you then go on to describe in sub-sections). I would suggest citing RFC 7754 and generalizing this text. = Section 2.1.6.1 = (1) How is the use case in this section different from the mention in 2.1.6 of "the user's pre-defined profile (e.g. for age sensitive content)"? (2) "In these cases, more granular (application layer) metadata may be used to analyze and block traffic, which will not work on encrypted content." I don't think it's appropriate to say that this technique "will not work" given the purpose of this document. There is already some evidence that network management that some folks probably thought was impossible given encrypted traffic actually is still possible (e.g., https://arxiv.org/abs/1607.01639). The same may be true for parental controls, we just may not know how to do it yet. I think it's fine to say that access to cleartext application-layer metadata is no longer possible, or something along those lines. = Section 2.1.7.3 = In Section 2 the text says: "The use of encryption prevents middle boxes from performing functions that range from some methods of load balancing to monitoring for attacks or enabling "lawful intercept", such that described in [ETSI101331] and [CALEA] in the US." This section says that lawful intercept is "impacted by encryption, typically by allowing a less granular means of implementation." So, is the claim that LI is prevented by encryption, or that it requires a change of implementation? These seem to be saying different things. = Section 2.1.7.4 = s/Real Time Session Protocol/Real Time Streaming Protocol/ = Section 2.1.7.5 = I would build on Ekr's comment here to say that even calling this technique header "enrichment" makes the text sound biased. Something like header "insertion" would be more neutral. = Section 2.2 = (1) I think this section would benefit from some commentary about how the fact that the "management" and "repair" of application traffic in the middle of the network might become more difficult could also be seen as an overall benefit, since lots of application providers and users see worse performance or user experience when the network tries to "manage" or "repair" their traffic. Some applications have been motivated to adopt encryption in order to avoid this to begin with. (2) "With the growing use of WebSockets ..." -- strictly speaking, this isn't related to encryption, because encryption is not mandatory to use with websockets. So I don't think it belongs in the document. = Section 3.2.2 = "STARTTLS ought have zero effect on anti-SPAM efforts for SMTP traffic. Anti-SPAM services could easily be performed on an SMTP gateway, eliminating the need for TLS decryption services." This text caught my eye because it seems to be in contrast to the descriptions provided in Section 2 (and the purpose of the draft as stated in Section 1), which seem to be driving more of a "the current way this is done is X, and X would not be possible in the same way anymore" message. Personally I would much prefer if the whole document were more in the vein of this text in 3.2.2., but given the framing in Section 1 it seems like re-framing the text here would be more appropriate. = Section 7 = "National surveillance programs have a clear need for monitoring terrorism [JNSLP] as do Internet security practitioners monitoring for criminal activities." To me these claims seem a bit out of place for an IETF RFC, and in general I agree with Ekr that it's probably better not to opine about the needs of various actors. = Section 11 = (1) Wherever this section lands, I think it needs a clear disclaimer up front that the problems are being described from the perspective of the mobile network provider. (2) Is the term "trusted proxy" defined in one of the references? If not, it seems like it needs a definition.
I hesitate to register concern here and I don't think the sky will fall if this is published but I the taxonomy insufficiently nuanced in a few areas of areas for me to consider this document as offering guidance. primarily The section on load balancing devices is essentially a caricature of broad field of devices that cover all sorts of variation from ethernet switches all the way up to ssl termination. Likewise content filtering covers a whole range of different approaches, actors and goals. whereas here we have the higly condensed version. I
conflict-review-irtf-nmrg-location-ipfix
I believe this is the wrong response and that we should return a response to the effect that this draft is extending an IETF protocol in a privacy sensitive manner and should therefore undergo an IETF LC. Or, I'd be fine with a DNP either. I raised this same point during IRSG review, yet there was no real discussion on that (that I saw) in the (is it?) six or so months since then. I do not think that clearing the decks for a new IRTF chair (as Lars has said he is doing by putting this up for conflict review) is a good enough reason to simply allow this pass. In fact, I think we ought be more willing to send a DNP or needs-IETF-LC response on that basis. The document itself clearly seems to envisage this location info being made available in a way that could directly track users. (" A typical example is a mobile device changing its location while exporting IP Flow records.") That the measurement ecosystem is not visible to users (and ought not be) is all the more reason to not want to have tracking added as a "feature" there - while ideas of "consent" on the Internet are badly broken, there seems to be basically no way in which a person could ever sensibly and knowledgeably agree to this kind of tracking. The security and privacy considerations are sadly lacking and would not IMO pass scrutiny in an IETF LC, (nor in the exam for my undergrad students;-), for example: "all Messages exchanged between Exporting and Collecting Processes SHOULD be signed and encrypted using Transport Layer Security (TLS) " ... is simply gibberish. TLS does not involve signing application data. That is yet another signal that this has not had and needs proper scrutiny. I note that the history here seems to be that this is an idea that garnered no traction in the IETF. We ought not allow this kind of workaround work for cases like that. And even moreso when (as in this case) the privacy issue was raised in IRSG review and no discussion whatsoever ensued. All in all: we should say no here.
I was going to enter a DISCUSS position about how the protections in BCP160 are inadequately conveyed by the language that it "MAY be applied..." But Alissa beat me to it. Otherwise, I agree with the rest of her comments, as well as Stephen's comments.
History information: My feedback on this draft has not changed (when it was draft-festor-ipfix-metering-process-location presented in IPFIX and draft-irtf-nmrg-location-ipfix in NMRG): authors, why don't you just request the IPFIX information elements from IANA? If they had gone the IANA route, they would have their IPFIX I.E.s by now. The authors have been pushing for years to publish their draft. They have requested feedback from IPFIX experts, but didn't go much information ... until lately with Paul Aitken (March 3rd," Review of draft-irtf-nmrg-location-ipfix-07.txt" on the IPFIX mailing list). btw, this is not a full review. However,, Paul Aitken, as the IANA expert, also provided feedback on the proposed IPFIX I.E.s part of draft-irtf-nmrg-location-ipfix-07 Cut and pasting Paul's latest information: Are you asking me to review draft-irtf-nmrg-location-ipfix before the telechat? Else, I would wait until there's a decision that it needs IETF review. Informally, all the technical content is reserved until the end. I've already reviewed section 6 and Appendix A for IANA under the IPFIX IE-doctors expert review process. Appendix B shows many incorrect IPFIX Templates which I've also already provided feedback for. I could review (rather than skim) the remainder of the draft in perhaps 1-2 hours. In short, this draft is a glorified IANA request. So if this document is published, it needs a version 8 based on the feedback provided and I needs 1-2 hours from Paul's time to make sure the entire document is fine from an IPFIX point of view. Now, back to the RFC5742 topic. 1. The IESG has concluded that there is no conflict between this document and IETF work. 2. The IESG has concluded that this work is related to IETF work done in WG <X>, but this relationship does not prevent publishing. 3. The IESG has concluded that publication could potentially disrupt the IETF work done in WG <X> and recommends not publishing the document at this time. 4. The IESG has concluded that this document violates IETF procedures for <Y> and should therefore not be published without IETF review and IESG approval. 5. The IESG has concluded that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. I would have chosen 6: document not necessary Now, assuming a version 8 with the Paul's first feedback and one more review (1-2 hours from Paul), the result is: 1. The IESG has concluded that there is no conflict between this document and IETF work. This document doesn't extend an IETF protocol (IPFIX) in a privacy-relevant manner, it just publishes some fields that contain some privacy-related information. That is the big distinction. From an OPS side, to configure the IPFIX metering process to monitor those new IPFIX information elements on a router, one needs to have the admin password. With this password, there are some many things that could be done in terms of privacy. So really, pretending that you will protect user privacy by not having this IPFIX I.E.s in IANA doesn't make sense to me. If the authors had requested those IPFIX I.E.s directly to IANA, nobody would have complained. Now, because it's a document, some wants "do not publish". I don't understand. Keep in mind that this is a "glorified IANA request".
I agree with Stephen's concerns.
I don't think this is the right conflict review response, for the two reasons below. I think one of the ones that requires IETF review and IESG approval might be, or DNP. First, this document makes recommendations inconsistent with BCP 160, which defines the location conveyance architecture that was standardized in the IETF in the GEOPRIV working group. The privacy properties of that architecture are not optional when attaching location to endpoints that identify targets, but this document says that their "usage MAY be applied to the IPFIX protocol when conveying location information." I consider that a conflict. Second, this document adds a column to an IANA registry that was defined in a standards-track RFC. Although the likelihood of interoperability problems as a result is small, I'm not sure this is really the right precedent to set. Should it really be the case that informational documents in the IRTF stream can change the structure of IANA registries defined in the standards track?
Work on ipfix was performed in the now concluded ipfix working group. Although this work was presented there, it was not adopted. The ipfix information model is extensible, entities are registrable under the under the procedure of expert review.