Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension
draft-ietf-manet-dlep-pause-extension-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-09-25
|
08 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-08-12
|
08 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-08-09
|
08 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-06-24
|
08 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-06-21
|
08 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2019-06-21
|
08 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2019-06-20
|
08 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-06-18
|
08 | (System) | RFC Editor state changed to EDIT |
2019-06-18
|
08 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-06-18
|
08 | (System) | Announcement was received by RFC Editor |
2019-06-17
|
08 | (System) | IANA Action state changed to In Progress |
2019-06-17
|
08 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-06-17
|
08 | Cindy Morgan | IESG has approved the document |
2019-06-17
|
08 | Cindy Morgan | Closed "Approve" ballot |
2019-06-17
|
08 | Alvaro Retana | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2019-06-17
|
08 | Alvaro Retana | Ballot approval text was generated |
2019-06-14
|
08 | Benjamin Kaduk | [Ballot comment] Thank you for resolving my Discuss points! |
2019-06-14
|
08 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-06-13
|
08 | Lou Berger | New version available: draft-ietf-manet-dlep-pause-extension-08.txt |
2019-06-13
|
08 | (System) | New version approved |
2019-06-13
|
08 | (System) | Request for posting confirmation emailed to previous authors: manet-chairs@ietf.org, Lou Berger , David Wiggins , Bow-Nan Cheng |
2019-06-13
|
08 | Lou Berger | Uploaded new revision |
2019-06-06
|
07 | Benjamin Kaduk | [Ballot discuss] [Future 'Scale' allocations will be done via Updates:] In Section 3.1.1: DS Field Qn: The data item contains a … [Ballot discuss] [Future 'Scale' allocations will be done via Updates:] In Section 3.1.1: DS Field Qn: The data item contains a sequence of 8 bit DS Fields. The number of DS Fields present MUST equal the sum of all Num DSCPs field values. Perhaps I'm misreading, but I thought the Num DSCPs Qn field was global for this queue index, so there would just be one of them and no need to take a sum. [Restart Data may not lead to data restart due to other conditions on the router] Section 4 The extension does not inherently introduce any additional vulnerabilities above those documented in [RFC8175]. [...] As noted by others, this sentence is just not true. I will not duplicate the suggestions for additional considerations that need to be documented. In particular, I agree with Roman that the use of TLS needs to be mandatory, especially since this protocol is nominally only defined for use with radio links. |
2019-06-06
|
07 | Benjamin Kaduk | Ballot discuss text updated for Benjamin Kaduk |
2019-06-06
|
07 | Mirja Kühlewind | [Ballot comment] Thanks for the discussion! |
2019-06-06
|
07 | Mirja Kühlewind | [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from Discuss |
2019-05-17
|
07 | Roman Danyliw | [Ballot comment] Thank you for addressing my DISCUSS. |
2019-05-17
|
07 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2019-05-10
|
07 | Alissa Cooper | [Ballot comment] DISCUSS cleared, leaving in my previous COMMENT: I support the DISCUSS positions of Warren and Magnus. I'm unclear on why this specification is … [Ballot comment] DISCUSS cleared, leaving in my previous COMMENT: I support the DISCUSS positions of Warren and Magnus. I'm unclear on why this specification is necessary, i.e. why the use of existing transport protocols and processing of DSCPs do not suffice to achieve what this specification is aiming to achieve. Is that explained in another document somewhere? = Section 1 = "Various flow control methods are possible, e.g., see [I-D.ietf-manet-dlep-da-credit-extension]." The referenced document does not specify a flow control method. Maybe draft-ietf-manet-dlep-credit-flow-control is what was intended? |
2019-05-10
|
07 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss |
2019-05-06
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-05-06
|
07 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-05-06
|
07 | Lou Berger | New version available: draft-ietf-manet-dlep-pause-extension-07.txt |
2019-05-06
|
07 | (System) | New version approved |
2019-05-06
|
07 | (System) | Request for posting confirmation emailed to previous authors: manet-chairs@ietf.org, Lou Berger , David Wiggins , Bow-Nan Cheng |
2019-05-06
|
07 | Lou Berger | Uploaded new revision |
2019-05-06
|
06 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss |
2019-04-11
|
06 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2019-04-11
|
06 | Warren Kumari | [Ballot comment] DISCUSS -> NoObj. Lou will add: Implementations of the extension defined in this document MUST support configuration of TLS usage, as … [Ballot comment] DISCUSS -> NoObj. Lou will add: Implementations of the extension defined in this document MUST support configuration of TLS usage, as describe in , in order to protect configurations where injection attacks are possible, i.e., when the link between a modem and router is not otherwise protected. to address my DISCUSS. --- Archived DISCUSS position for hysterical raisins --- Please note that I'm really not a DLEP person, and so this may be completely incorrect -- in which case I'm (of course!) happy to clear my discuss. Hypothetical Scenario: My next-door neighbor keeps using up all the bandwidth, making my Internets slow! Stupid neighbor! Until now I didn't have much motivation to mess with DLEP (it didn't really gain me anything), but now I can spoof Pause Data Items to get the router to stop sending traffic to her, freeing up all the bandwidth for me. The security considerations section doesn't *really* cover this -- it says: " Note that this extension does allow a compromised or impersonating modem to suppress transmission by the router, but this is not a substantively different attack by such a compromised modem simply dropping all traffic destined to, or sent by a router." -- that only covers compromised modems, not impersonating modems. It also says: "[RFC8175] defines the use of TLS to protect against the impersonating attacker." -- yes, RFC8175 does indeed define the use of TLS, but doesn't require it. RFC8175 Security Considerations also say: " This specification does not address security of the data plane, as it (the data plane) is not affected, and standard security procedures can be employed." and "Similar issues can arise if DLEP data is used as an input to policing algorithms -- injection of malicious data via DLEP can cause those policing algorithms to make incorrect decisions, degrading network throughput." It seems that this specification is specifically allowing the dataplane to be affected by (spoofed) DLEP messages, and in a much more direct way than discussed in the RFC8175 security considerations section. I think that this is dangerous without much more direct advice (like "MUST use TLS" or similar). ------- |
2019-04-11
|
06 | Warren Kumari | [Ballot Position Update] Position for Warren Kumari has been changed to No Objection from Discuss |
2019-04-10
|
06 | Benjamin Kaduk | [Ballot discuss] Section 3.1 defines 'Scale' as a four-bit unsigned integer field but only the values 0-3 are assigned, leaving 4-16k usable. How will future … [Ballot discuss] Section 3.1 defines 'Scale' as a four-bit unsigned integer field but only the values 0-3 are assigned, leaving 4-16k usable. How will future values be assigned? In Section 3.1.1: DS Field Qn: The data item contains a sequence of 8 bit DS Fields. The number of DS Fields present MUST equal the sum of all Num DSCPs field values. Perhaps I'm misreading, but I thought the Num DSCPs Qn field was global for this queue index, so there would just be one of them and no need to take a sum. In Section 3.3: A router which receives the Restart Data Item SHOULD resume transmission of the identified traffic to the modem. Why is this only a "SHOULD"? Section 4 The extension does not inherently introduce any additional vulnerabilities above those documented in [RFC8175]. [...] As noted by others, this sentence is just not true. I will not duplicate the suggestions for additional considerations that need to be documented. In particular, I agree with Roman that the use of TLS needs to be mandatory, especially since this protocol is nominally only defined for use with radio links. |
2019-04-10
|
06 | Benjamin Kaduk | [Ballot comment] Section 3.1 Any errors or inconsistencies … [Ballot comment] Section 3.1 Any errors or inconsistencies encountered in parsing Sub Data Items are handled in the same fashion as any other Data Item parsing error encountered in DLEP. I had a hard time finding the indicated behavior in RFC 8175 -- "error" does not appear at all (and "erroneous" only twice, for IP address processing, v4 and v6); "parse" only appears once (in the Session Initialization State); "inconsistent" apprears several times but I did not see one that seemed to be a generic catch-all case. It's probably worth putting in a section reference or changing the text to use keywords that are searchable in RFC 8175. Section 3.1.1 Queue Size Qn: A 24-bit unsigned integer representing the size, in the octet scale indicated by the Scale field, of the queue supporting traffic with the DSCPs associated with the queue index. Is there any value in including a specific sentinel value that indicates that the modem cannot or does not wish to state the size of the corresponding queue? Section 3.2 A router which receives the Pause Data Item MUST cease sending the identified traffic to the modem. This may of course translate into the router's queues exceeding their own thresholds. If a received Pause Data Item contains a Queue Index value other than 255, or a queue index established by a Session Initialization or Session Update Message, the router MUST terminate the session with a Status Data Item indicating Invalid Data. This would be a nit, but actually has serious functional consequences: remove the comma after "255". The current text says that if the router receives a queue index established by a Session Initialization message, the router MUST terminate the session, which does not seem to be the intent! Section 3.3 The Restart Data Item is used by a modem to indicate to its peer that transmission of previously suppressed traffic may be resumed. An example of when a modem might send this data item is when an internal queue length drops below a particular threshold. This seems like a fine place to suggest the application of hysteresis (i.e., that the "particular threshold" here might be lower than the one indicated in Section 3.2). Section 5.x It's not clear to me what value there is in repeating the registration policy of the registries from which codepoints are being allocated. IANA will apply the correct policy, and the reader of this document doesn't need to care what policy was applied. |
2019-04-10
|
06 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-04-10
|
06 | Adam Roach | [Ballot comment] Thanks to everyone who worked on this document. I share Roman and Warren's concerns about authentication of pause messages. --------------------------------------------------------------------------- §3.2: > particular … [Ballot comment] Thanks to everyone who worked on this document. I share Roman and Warren's concerns about authentication of pause messages. --------------------------------------------------------------------------- §3.2: > particular threshold. Other use cases are possible, e.g., when there > a non queue related congestion points within a modem, but such are Nit: I can't quite parse the "when there a non queue" part of this. |
2019-04-10
|
06 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2019-04-10
|
06 | Roman Danyliw | [Ballot discuss] Unauthenticated shutdown of the network seems exceedingly dangerous. An expansion of the implementation scenarios described in Section 4 of RFC8175 and the architecture … [Ballot discuss] Unauthenticated shutdown of the network seems exceedingly dangerous. An expansion of the implementation scenarios described in Section 4 of RFC8175 and the architecture laid out in Figure 1 of RFC8175 appears to be: (a) single direct connect (1x modem + 1x router) (b) single dedicated switch (1x modem + 1x switch + 1x router) (c) multiple connect (>1x modem + >=0 switches + 1x router) (d) mobile environment (>=1x modem + switch + router + other devices in the switch) (e) networked deployment (as stated in RFC8175/anything more complicated) I believe that the safest thing is that using TLS with this extension should be a MUST. If that is problematic, then I’d only soften it to (text that amounts to) “in environments and deployment scenarios (a) and (b), TLS SHOULD be used. In all other environments, TLS MUST be used.” Warren: I believe that your neighbor scenario is likely scenario (c). As the current security considerations say, using TLS in scenario (a) won’t help if the modem gets compromised. In the above recommendation, there is an assumption that the switch(s) isn’t compromised (and that should be documented). |
2019-04-10
|
06 | Roman Danyliw | [Ballot comment] (0) I support Warren and Magnus’s DISCUSS positions. (1) Section 3.1. Per the Query Parameters data item, what is the router behavior when … [Ballot comment] (0) I support Warren and Magnus’s DISCUSS positions. (1) Section 3.1. Per the Query Parameters data item, what is the router behavior when it receives: ** Num Queues = 0 ** Num Queues <> the queues sent? (2) Section 3.1. Nit. The size of the Reserved field is not indicated in the text (like the other fields) (3) Section 3.1.1, Please provide a section reference into RFC8175 on error parsing. (4) Section 3.2 Per “Each Pause Data Item identifies the traffic to be suppressed by the Queue Index defined by Section 3.1”, am I reading it right that a Queue Parameter Data Item needs to be sent before a Pause is sent? If so, I’m not sure that is said anywhere and should be. Furthermore, how does a router behave if it does get a Pause message prior to getting a Parameter Data Item message? (5) Section 3.3 Related to comment-4, How does a router behave if it gets a Restart message prior to getting a Parameter Data Item or Pause message? |
2019-04-10
|
06 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2019-04-10
|
06 | Alissa Cooper | [Ballot discuss] This work item does not appear to be inside the scope of the MANET charter, at least based on my reading of the … [Ballot discuss] This work item does not appear to be inside the scope of the MANET charter, at least based on my reading of the charter. Am I missing something? |
2019-04-10
|
06 | Alissa Cooper | [Ballot comment] I support the DISCUSS positions of Warren and Magnus. I'm unclear on why this specification is necessary, i.e. why the use of existing … [Ballot comment] I support the DISCUSS positions of Warren and Magnus. I'm unclear on why this specification is necessary, i.e. why the use of existing transport protocols and processing of DSCPs do not suffice to achieve what this specification is aiming to achieve. Is that explained in another document somewhere? = Section 1 = "Various flow control methods are possible, e.g., see [I-D.ietf-manet-dlep-da-credit-extension]." The referenced document does not specify a flow control method. Maybe draft-ietf-manet-dlep-credit-flow-control is what was intended? |
2019-04-10
|
06 | Alissa Cooper | Ballot comment and discuss text updated for Alissa Cooper |
2019-04-10
|
06 | Alissa Cooper | [Ballot discuss] I support the DISCUSS positions of Warren and Magnus. Also, this work item does not appear to be inside the scope of the … [Ballot discuss] I support the DISCUSS positions of Warren and Magnus. Also, this work item does not appear to be inside the scope of the MANET charter, at least based on my reading of the charter. Am I missing something? |
2019-04-10
|
06 | Alissa Cooper | [Ballot comment] I'm unclear on why this specification is necessary, i.e. why the use of existing transport protocols and processing of DSCPs do not suffice … [Ballot comment] I'm unclear on why this specification is necessary, i.e. why the use of existing transport protocols and processing of DSCPs do not suffice to achieve what this specification is aiming to achieve. Is that explained in another document somewhere? = Section 1 = "Various flow control methods are possible, e.g., see [I-D.ietf-manet-dlep-da-credit-extension]." The referenced document does not specify a flow control method. Maybe draft-ietf-manet-dlep-credit-flow-control is what was intended? |
2019-04-10
|
06 | Alissa Cooper | [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper |
2019-04-10
|
06 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-04-09
|
06 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-04-09
|
06 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-04-08
|
06 | Warren Kumari | [Ballot discuss] Please note that I'm really not a DLEP person, and so this may be completely incorrect -- in which case I'm (of course!) … [Ballot discuss] Please note that I'm really not a DLEP person, and so this may be completely incorrect -- in which case I'm (of course!) happy to clear my discuss. Hypothetical Scenario: My next-door neighbor keeps using up all the bandwidth, making my Internets slow! Stupid neighbor! Until now I didn't have much motivation to mess with DLEP (it didn't really gain me anything), but now I can spoof Pause Data Items to get the router to stop sending traffic to her, freeing up all the bandwidth for me. The security considerations section doesn't *really* cover this -- it says: " Note that this extension does allow a compromised or impersonating modem to suppress transmission by the router, but this is not a substantively different attack by such a compromised modem simply dropping all traffic destined to, or sent by a router." -- that only covers compromised modems, not impersonating modems. It also says: "[RFC8175] defines the use of TLS to protect against the impersonating attacker." -- yes, RFC8175 does indeed define the use of TLS, but doesn't require it. RFC8175 Security Considerations also say: " This specification does not address security of the data plane, as it (the data plane) is not affected, and standard security procedures can be employed." and "Similar issues can arise if DLEP data is used as an input to policing algorithms -- injection of malicious data via DLEP can cause those policing algorithms to make incorrect decisions, degrading network throughput." It seems that this specification is specifically allowing the dataplane to be affected by (spoofed) DLEP messages, and in a much more direct way than discussed in the RFC8175 security considerations section. I think that this is dangerous without much more direct advice (like "MUST use TLS" or similar). |
2019-04-08
|
06 | Warren Kumari | [Ballot Position Update] New position, Discuss, has been recorded for Warren Kumari |
2019-04-08
|
06 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2019-04-07
|
06 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2019-04-06
|
06 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2019-04-04
|
06 | Bob Briscoe | Request for Last Call review by TSVART Completed: On the Right Track. Reviewer: Bob Briscoe. Sent review to list. |
2019-04-04
|
06 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2019-04-04
|
06 | Mirja Kühlewind | [Ballot discuss] I have similar questions as Magnus does about the specific use case for this mechanism. Moreover I wonder about the assumed usage of … [Ballot discuss] I have similar questions as Magnus does about the specific use case for this mechanism. Moreover I wonder about the assumed usage of the different DSCPs. If the router would want to assign code points to the traffic, then it would need to know what the requirements of the traffic is which is usually unknown to a router. If there is an assumption that the traffic is marked with the right DSCP by the origin than the router does not need to know about the available DS queue configuration. Can you please clarify! |
2019-04-04
|
06 | Mirja Kühlewind | Ballot discuss text updated for Mirja Kühlewind |
2019-04-04
|
06 | Mirja Kühlewind | [Ballot discuss] I have similar questions as Magnus does about the specific use case for this mechanism. Moreover I wonder about the assumed usage of … [Ballot discuss] I have similar questions as Magnus does about the specific use case for this mechanism. Moreover I wonder about the assumed usage of the different DSCPs. If he router would want to assign assign code points to the traffic, then it would need to know what the requirement of the traffic is which is usually unknown. If there is an assumption that the traffic is marked with the right DSCP by the origin than the router does not need to know about the available DS queue configuration. Can you please clarify! |
2019-04-04
|
06 | Mirja Kühlewind | [Ballot Position Update] New position, Discuss, has been recorded for Mirja Kühlewind |
2019-04-04
|
06 | Magnus Westerlund | [Ballot discuss] It is unclear to me what the purpose of the pause and resume is here? Is it to enable the router to build … [Ballot discuss] It is unclear to me what the purpose of the pause and resume is here? Is it to enable the router to build the queue rather than the modem if there is a queue buildup in the modem? If that is the case, then pause and resume will be done frequently and on short time scales due to variability of the link. And then the router resumes transmission to the modem when the buffer has been reduced? As this is enabled to be done on a queue level what how does one ensure the per hop behavior that is intended based on the DSCP with this split. Because you will get an interaction between the two queue that are in series for the same link which makes ensuring the PHB difficult. I hope for a timely clarification to determine if this is a discuss or not and make it more actionable. |
2019-04-04
|
06 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund |
2019-04-03
|
06 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2019-04-03
|
06 | Lou Berger | New version available: draft-ietf-manet-dlep-pause-extension-06.txt |
2019-04-03
|
06 | (System) | New version approved |
2019-04-03
|
06 | (System) | Request for posting confirmation emailed to previous authors: manet-chairs@ietf.org, Lou Berger , David Wiggins , Bow-Nan Cheng |
2019-04-03
|
06 | Lou Berger | Uploaded new revision |
2019-04-03
|
05 | Amy Vezza | Placed on agenda for telechat - 2019-04-11 |
2019-04-03
|
05 | Alvaro Retana | IESG state changed to IESG Evaluation from Waiting for Writeup |
2019-04-03
|
05 | Alvaro Retana | Ballot has been issued |
2019-04-03
|
05 | Alvaro Retana | [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana |
2019-04-03
|
05 | Alvaro Retana | Created "Approve" ballot |
2019-04-03
|
05 | Alvaro Retana | Ballot writeup was changed |
2019-04-03
|
05 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-04-02
|
05 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2019-04-02
|
05 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-manet-dlep-pause-extension-05. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-manet-dlep-pause-extension-05. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete. In the Extension Type Values registry on the Dynamic Link Exchange Protocol (DLEP) Parameters registry page located at: https://www.iana.org/assignments/dlep-parameters/ a single new value is to be registered from the existing unassigned range as follows: Code: [ TBD-at-Registration ] Description: Control Plane Based Pause Reference: [ RFC-to-be ] As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Second, in the Data Item Type Values registry also on the Dynamic Link Exchange Protocol (DLEP) Parameters registry page located at: https://www.iana.org/assignments/dlep-parameters/ three new registrations are to be made as follows: Type Code: [ TBD-at-Registration ] Description: Queue Parameters Reference: [ RFC-to-be ] Type Code: [ TBD-at-Registration ] Description: Pause Reference: [ RFC-to-be ] Type Code: [ TBD-at-Registration ] Description: Restart Reference: [ RFC-to-be ] As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Third, a new registry is to be created called the Queue Parameters Sub Data Item Type Values registry. The new registry will be located on the Dynamic Link Exchange Protocol (DLEP) Parameters registry page located at: https://www.iana.org/assignments/dlep-parameters/ Values 0-65407 are managed via Specification Required and values 65408-65534 are managed via Private Use as defined by RFC 8126. Value 65535 is reserved. There are initial registrations in the new registry as follows: Type Code: Description: Reference: -----------+------------------------------+----------------- 0 Reserved 1 Queue Parameter [ RFC-to-be ] 2-65407 Unassigned 65408-65534 Private Use 65535 Reserved The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-03-29
|
05 | Andy Smith | Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Andy Smith. Sent review to list. |
2019-03-25
|
05 | Min Ye | Request for Last Call review by RTGDIR is assigned to Andy Smith |
2019-03-25
|
05 | Min Ye | Request for Last Call review by RTGDIR is assigned to Andy Smith |
2019-03-24
|
05 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Bob Briscoe |
2019-03-24
|
05 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Bob Briscoe |
2019-03-20
|
05 | Dale Worley | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Dale Worley. Sent review to list. |
2019-03-20
|
05 | Stephen Kent | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Stephen Kent. Sent review to list. |
2019-03-14
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dale Worley |
2019-03-14
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dale Worley |
2019-03-14
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stephen Kent |
2019-03-14
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stephen Kent |
2019-03-14
|
05 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Withdrawn' |
2019-03-14
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Dan Harkins |
2019-03-14
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Dan Harkins |
2019-03-14
|
05 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2019-03-14
|
05 | Amy Vezza | The following Last Call announcement was sent out (ends 2019-04-03): From: The IESG To: IETF-Announce CC: draft-ietf-manet-dlep-pause-extension@ietf.org, sratliff@idirect.net, Stan Ratliff , manet-chairs@ietf.org, … The following Last Call announcement was sent out (ends 2019-04-03): From: The IESG To: IETF-Announce CC: draft-ietf-manet-dlep-pause-extension@ietf.org, sratliff@idirect.net, Stan Ratliff , manet-chairs@ietf.org, manet@ietf.org, aretana.ietf@gmail.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (DLEP Control Plane Based Pause Extension) to Proposed Standard The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'DLEP Control Plane Based Pause Extension' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-04-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines an extension to the DLEP protocol that enables a modem to use DLEP messages to pause and resume data traffic coming from its peer router. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-pause-extension/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-pause-extension/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-03-14
|
05 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2019-03-14
|
05 | Min Ye | Request for Last Call review by RTGDIR is assigned to Victoria Pritchard |
2019-03-14
|
05 | Min Ye | Request for Last Call review by RTGDIR is assigned to Victoria Pritchard |
2019-03-13
|
05 | Alvaro Retana | Requested Last Call review by RTGDIR |
2019-03-13
|
05 | Alvaro Retana | Last call was requested |
2019-03-13
|
05 | Alvaro Retana | Ballot approval text was generated |
2019-03-13
|
05 | Alvaro Retana | Ballot writeup was generated |
2019-03-13
|
05 | Alvaro Retana | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2019-03-13
|
05 | Alvaro Retana | Last call announcement was changed |
2019-03-13
|
05 | Alvaro Retana | Last call announcement was generated |
2019-03-11
|
05 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-03-11
|
05 | Lou Berger | New version available: draft-ietf-manet-dlep-pause-extension-05.txt |
2019-03-11
|
05 | (System) | New version approved |
2019-03-11
|
05 | (System) | Request for posting confirmation emailed to previous authors: manet-chairs@ietf.org, Lou Berger , David Wiggins , Bow-Nan Cheng |
2019-03-11
|
05 | Lou Berger | Uploaded new revision |
2018-11-16
|
04 | Alvaro Retana | === AD Evaluation of draft-ietf-manet-dlep-pause-extension-04 === https://mailarchive.ietf.org/arch/msg/manet/YMwOuhXt-D9-6eJA2B9B-3YkfZQ Dear authors: I just finished reviewing this document. I have several comments (see below) and a couple of … === AD Evaluation of draft-ietf-manet-dlep-pause-extension-04 === https://mailarchive.ietf.org/arch/msg/manet/YMwOuhXt-D9-6eJA2B9B-3YkfZQ Dear authors: I just finished reviewing this document. I have several comments (see below) and a couple of significant issues, which I'm mentioning in the next 2 bullets. I will wait for these to be addressed before starting the IETF LC. (1) This is a comment for the WG (not just the authors): This is the first draft that specifies a Sub Data Item. Given that rfc8175 says that the Value in a Data Item "contains data specific to a particular Data Item", I don't think it is necessary to define a generic DLEP Sub Data Item. However, not all future extensions may follow the same model. Is there a need/interest in normatively specifying the characteristics of a Sub Data Item? (2) Security Considerations: The extension in itself doesn't change the security characteristics of DLEP, I agree with that. However, I think that the functionality does -- please see specific comments below. Thanks! Alvaro. [Line numbers from idnits.] ... 70 1. Introduction ... 78 The base DLEP specification does not include any data plane flow 79 control capability. Various flow control methods are possible, e.g., 80 see [I-D.ietf-manet-credit-window]. The extension defined in this ... [minor] A reference to something other than I-D.ietf-manet-credit-window (expired, etc.) may be more appropriate. ... 103 2. Extension Usage and Identification 105 The use of the Control Plane Based Pause Extension SHOULD be 106 configurable. To indicate that the Control Plane Based Pause 107 Extension is to be used, an implementation MUST include the Control 108 Plane Based Pause Extension Type Value in the Extensions Supported 109 Data Item. The Extensions Supported Data Item is sent and processed 110 according to [RFC8175]. [minor] "The use of the Control Plane Based Pause Extension SHOULD be configurable." Is there a default recommended configuration? ... 201 3.1.1. Queue Parameter Sub Data Item ... 234 Sub Data Item Type: 236 A 16-bit unsigned integer that indicates the type and 237 corresponding format of the Sub Data Item's Value field. Sub Data 238 Item Types are scoped within the Data Item in which they are 239 carried, i.e., the Sub Data Item Type field MUST be used together 240 with the Data Item Type to identify the format of the Sub Data 241 Item. This field MUST be set to one (1) for the Queue Parameter 242 Sub Data Item. [minor] "...the Sub Data Item Type field MUST be used together with the Data Item Type to identify the format of the Sub Data Item." It sounds as if this text wants to specify the behavior for *any* Sub Data Item Type. Please reword to be specific in to this document. [Also, see my note at the top.] [major] Please define a registry for the Sub Data Item Types to be used with the Queue Parameters Data Item. 244 Length: Variable 246 Copying [RFC8175], Length is the number of octets in the sub data 247 item, excluding the Type and Length fields. [minor] Copying? As far as I can tell, rfc8175 doesn't define any sub data items. 249 Queue Index: 251 An 8-bit field indicating the queue index of the queue parameter 252 represented in the sub data item. Only the first instance a a 253 particular Queue Index value is meaningful. Subsequent sub data 254 items containing the same Queue Index values, if present, MAY be 255 logged via a management interface and MUST otherwise be ignored. [nit] s/a a/of a [minor] Pause and Restart reserve the Queue Index of 255 to indicate "all traffic", but that value is not reserved here. Should it? ... 269 DS Field Qn: 271 The data item contains a sequence of 8 bit DS Fields. The 272 position in the sequence identifies the associated queue index. 273 The number of DS Fields present should equal the sum of all Num 274 DSCPs field values. [major] "should equal", or "MUST equal"? If the number of DS Fields doesn't add up, should the sub data item be considered invalid? I assume that would invalidate the whole data item. ... 286 3.2. Pause ... 293 A modem may indicate that traffic is to be suppressed on a device 294 wide or destination specific basis. An example of when a modem might 295 use device wide indications is when output queues are shared across 296 all destinations, and destination specific might be used when per 297 destination queuing is used. To indicate that suppression applies to 298 all destinations, a modem MAY send the Pause Data Item in a Session 299 Update Message. To indicate that suppression applies to a particular 300 destination a modem MAY send the Pause Data Item in a Destination 301 Update Message. [major] I think that the two MAYs above are out of place. I understand that sending the Pause Data Item in the corresponding Update Message is optional, but the sentences say that "To indicate that suppression applies...", which means that if the Pause Data Item is not sent, then there is no indication...so sending it is not optional. ... 312 A router which receives the Pause Data Item MUST cease sending the 313 identified traffic to the modem. This may of course translate into 314 the router's queues exceeding their own thresholds. If a received 315 Pause Data Item contains a Queue Index value other than 0, 255, or a 316 queue index established by a Session Initialization or Session Update 317 Message, the router MUST terminate the session with a Status Data 318 Item indicating Invalid Data. [major] Terminating the session seems drastic to me given that the wrong index relates to a single destination and the action has an impact over all. ... 347 3.3. Restart ... 354 The sending of this data item parallels the Pause Data Item, see the 355 previous section, and follows the same rules. This includes that to 356 indicate that transmission can resume to all destinations, a modem 357 MAY send the Restart Data Item in a Session Update Message. It also 358 includes that to indicate that transmission can resume to a 359 particular destination a modem MAY send the Pause Restart Item in a 360 Destination Update Message. Finally, the same rules apply to queue 361 indexes. [major] Same comment as above about the MAYs. 363 A router which receives the Restart Data Item SHOULD resume 364 transmission of the identified traffic to the modem. [minor] Should the Restart always follow a Pause? I think that is the intent. The question is whether it MUST happen that way? As is, the text leaves the possibility open for a modem to send a Restart without having sent a Pause. I think that is ok, just checking... ... 384 4. Security Considerations 386 The extension introduces a new mechanism for flow control between a 387 router and modem using the DLEP protocol. The extension does not 388 inherently introduce any additional threats above those documented in 389 [RFC8175]. The approach taken to Security in that document applies 390 equally when running the extension defined in this document. [major] The extension gives the modem the ability to stop the traffic sent by a router. A rogue or compromised modem could stop traffic sent by the attached router. Protecting the modem is out of scope, but I think the threat should at least be pointed out. rfc8175 already mentions the risk that "an attacker might pretend to be a DLEP participant...by injection of DLEP Messages once a session has been established", which is related to this case. However, I think that the point still needs to be called out specifically because of the new functionality introduced. ... 466 Appendix A. Acknowledgments 468 The sub data item format was inspired by Rick Taylor's "Data Item 469 Containers". [nit] Is this a draft? Reference? |
2018-11-16
|
04 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-11-14
|
04 | Alvaro Retana | This document now replaces draft-cheng-manet-dlep-pause-extension instead of None |
2018-10-16
|
04 | Alvaro Retana | IESG state changed to AD Evaluation from Publication Requested |
2018-10-16
|
04 | Alvaro Retana | Notification list changed to Stan Ratliff <sratliff@idirect.net>, aretana.ietf@gmail.com from Stan Ratliff <sratliff@idirect.net> |
2018-08-13
|
04 | Amy Vezza | Changed consensus to Yes from Unknown |
2018-08-13
|
04 | Amy Vezza | Intended Status changed to Proposed Standard from None |
2018-08-13
|
04 | Stan Ratliff | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) The document is being submitted as a proposed standard, because it documents an extension of functionality for DLEP itself (RFC 8175). The document is marked "Standards Track". (2) Technical Summary This document defines an extension to the DLEP protocol that enables a modem to use DLEP messages to pause and resume data traffic coming from its peer router. Working Group Summary The WG process was smooth, there are no issues or concerns arising from this document. Document Quality The document is clear and well-written. To the shpeherd's knowledge, there are no implementations of the document. However, vendors have indicated a plan to implement the document once published. The document does not reference a MIB, or specific Media Type. Therefore, no extpert reviews were necessary. Personnel The Document Shepherd is Stan Ratliff. The Responsible Area Director is Alvaro Retana. (3) The Shepherd has reviewed the document; no issues were noticed. (4) The Shepherd has no concerns about the depth or breadth of the reviews done. (5) No expert reviews are needed from other groups or areas. The document describes an extension to the DLEP protocol. (6) The Shepherd has no concerns or issues with the document. (7) All IPR disclosures have been filed by all of the authors. No IPR exists. (8) No IPR exists. (9) The WG consensus is strong, amongst the DLEP experts in the group. Some have been silent on the issue, as this technology does not coincide with their interests. (10) No appeals have been threatened, or even discussed. (11) No nits were found. (12) The document does not reference MIBs, media types, or URIs. Therefore, no formal reviews of that type were required. (13) All references are defined as either normative or informative. (14) All normative references are to documents already published as RFCs. (15) No downward references exist. (16) The document will not change the status of any existing document. (17) The Shepherd reviewed the IANA considerations, and found them to be consistent with both current IANA process, and with the document itself. No new registries are defined. (18) The DLEP Extensions Registry "Extension Type Values" requires expert review. The experts for that registry have already been communicated to IANA. (19) No XML code, BNF rules, or MIB definitions exist in the document. |
2018-08-13
|
04 | Stan Ratliff | Responsible AD changed to Alvaro Retana |
2018-08-13
|
04 | Stan Ratliff | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-08-13
|
04 | Stan Ratliff | IESG state changed to Publication Requested |
2018-08-13
|
04 | Stan Ratliff | IESG process started in state Publication Requested |
2018-08-13
|
04 | Stan Ratliff | Changed document writeup |
2018-08-13
|
04 | Stan Ratliff | Notification list changed to Stan Ratliff <sratliff@idirect.net> |
2018-08-13
|
04 | Stan Ratliff | Document shepherd changed to Stan Ratliff |
2018-06-15
|
04 | Lou Berger | New version available: draft-ietf-manet-dlep-pause-extension-04.txt |
2018-06-15
|
04 | (System) | New version approved |
2018-06-15
|
04 | (System) | Request for posting confirmation emailed to previous authors: manet-chairs@ietf.org, Lou Berger , David Wiggins , Bow-Nan Cheng |
2018-06-15
|
04 | Lou Berger | Uploaded new revision |
2018-05-14
|
03 | Stan Ratliff | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2018-03-01
|
03 | Lou Berger | New version available: draft-ietf-manet-dlep-pause-extension-03.txt |
2018-03-01
|
03 | (System) | New version approved |
2018-03-01
|
03 | (System) | Request for posting confirmation emailed to previous authors: manet-chairs@ietf.org, Lou Berger , David Wiggins , Bow-Nan Cheng |
2018-03-01
|
03 | Lou Berger | Uploaded new revision |
2017-10-30
|
02 | Lou Berger | New version available: draft-ietf-manet-dlep-pause-extension-02.txt |
2017-10-30
|
02 | (System) | New version approved |
2017-10-30
|
02 | (System) | Request for posting confirmation emailed to previous authors: manet-chairs@ietf.org, Lou Berger , David Wiggins , Bow-Nan Cheng |
2017-10-30
|
02 | Lou Berger | Uploaded new revision |
2017-07-03
|
01 | Lou Berger | New version available: draft-ietf-manet-dlep-pause-extension-01.txt |
2017-07-03
|
01 | (System) | New version approved |
2017-07-03
|
01 | (System) | Request for posting confirmation emailed to previous authors: Bow-Nan Cheng , Lou Berger , David Wiggins , manet-chairs@ietf.org |
2017-07-03
|
01 | Lou Berger | Uploaded new revision |
2017-02-09
|
00 | Lou Berger | New version available: draft-ietf-manet-dlep-pause-extension-00.txt |
2017-02-09
|
00 | (System) | WG -00 approved |
2017-02-09
|
00 | Lou Berger | Set submitter to "Lou Berger ", replaces to (none) and sent approval email to group chairs: manet-chairs@ietf.org |
2017-02-09
|
00 | Lou Berger | Uploaded new revision |