IPv6 Performance and Diagnostic Metrics (PDM) Destination Option
draft-ietf-ippm-6man-pdm-option-13

[ Comments below already already discussed - just keeping them here for history ] 
This document defines a new IPv6 Destination Option. Adding this to a packet pushes the L4 information further out, potentially making it unavailable to the forwarding engine / ACLs. This is not just a theoretical issue - see RFC7872 for real world examples. This means that if I connect to a remote machine and enable this, I may lock myself out of the machine (return packets may not make it back to me); this should be noted (perhaps by expanding on section 1.6). In addition, enabling PDM will (almost definitely) add some processing / transmit time, and so will perturb the very thing being measured - I believe that the document should note this. Appendix C mentions overhead from larger packets, but nothing about the additional processing time.

In addition, much of the security advice feels like sops, simply to appease security people. For example, in "PDM as a Covert Channel" we find: "Having said that, an implementation SHOULD stop using PDM if it gets some number of "nonsensical" sequence numbers."  -- seeing as it would be the attacker using PDM as a convert channel, this is like saying attackers must set the evil bit on all attack traffic.

Another example is section 4.4 Timing Attacks:
"Even so, if using PDM, we introduce the concept of user "Consent to be Measured" as a pre-requisite for using PDM.  Consent is common in enterprises and with some subscription services. So, if with PDM, we recommend that the user SHOULD consent to its use." - this has nothing to do with timing attacks. In addition a concept is introduced, but not really explained - it is then claimed that this is common in enterprises (true), and that users SHOULD consent (or should have already consented) to being monitored. This feels like it was sprinkled on like security fairy dust to make security people happy, and (for me) does the opposite.


I don't understand Section 3.6 Dynamic Configuration Options.
"If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=yes/no. The operating system MAY also have a dynamic configuration option to change the configuration setting as needed."
I don't understand how an implementing OS could not have a default (unless this were random). If the default were no, presumably it would *have* to have a dynamic option to change the config (or it could never be enabled).
Section 3.5.1 says: "The PDM destination options extension header MUST be explicitly  turned on by each stack on a host node by administrative action. The  default value of PDM is off.", so I'm very confused what 3.6 is trying to say...

I agree with Warren's DISCUSS.

In Sec 3.2.1, it specifies "Delta Time Last Received = (Send time packet 2 - Receive time packet 1)"
&   "Delta Time Last Sent = (Receive time packet 2 - Send time packet 1)".  I think this would be clearer
and not subject to misinterpretation if it were "n" and "n-1" - with words indicating wrapping cases.

The analysis in Sec 4.2 seems to be missing some considerations. In cases where the packet payload is encrypted and the attacker does not have access to the keys, the attacker does not in fact have access to the entire packet, in which case PDM provides more information than a packet without PDM. Also in those cases, it seems like including PDM information would generally make a packet stream more susceptible to traffic analysis insofar as the timing and sequence information may provide additional indicators about the type of application in use, not just the speed of the end host.

In Section 3.2.1. (PDM Layout), please include all the considerations related to the Option Type in the same place.

Substantive Comments:

- 1.4, 2nd to last paragraph: Please don't make assumptions about organizational models; different organizations do it differently. Does the motivation still make sense if the organization doesn't follow this model?

- 1.5, first paragraph: "The purpose of the PDM is not to supplant all the variables present
   in all other headers but to provide data which is not available or
   very difficult to get."
How is that different than for any other extension?

3.2.1, PSNTP definition:

What are the consequences if people "spoof and insert such
   packets."?

- 3.2.2: Are there really use cases for attosecond precision?

- 4.1, last paragraph: Can you provide guidance on selecting a reasonable limit? At least a lower bound so that the limit does not negatively impact the PDM function?

-4.2: 
Could PDM be used to (help) deduce the nature of the application, or possibly network topology? The last paragraph says it will be unhelpful in deducing content; I suspect otherwise. Section 4.4 talks about how it might help timing attacks against key material.

Does PDM really offer no more information to an observer than they could get by observing packet intervals of otherwise encrypted traffic? For example, it seems like one could not differentiate between wire-time and processing-time from observation alone.

-4.4, 2nd paragraph: Why does the attacker need to induce the host to turn on PDM? What about cases where the host already uses PDM?

-- last paragraph:The text recommends that a user SHOULD consent. I think you mean to say that user consent SHOULD be required. They mean very different things.

But along those lines, do you expect the average user to make informed consent decisions? At what scope should such decisions be made? Some OSs ask a user if they are willing to share diagnostic info at a global level. Does the guidance about using PDM on limited IP addresses or ports suggest consent apply at a smaller granularity?

Editorial Comments:

-General: Much of the text reads more like a white paper than an IETF standards-track RFC. This makes some sections seem like advertisements. The heavy use of "we" calls into question whether it documents the opinions of the WG, or the opinions of the authors. It also makes some sections longer than they need to be (e.g. the discussions related to time scaling factors read more like a classroom lecture than a specification.) I recognize that fixing this would require a re-write. I will leave it to the authors, chairs, and AD to decide if that is worthwhile this late in the process.

- Abstract: Last sentence is long and convoluted. Please consider breaking it up.

- 1.4, list of advantages: How is 5 different than 2?
-- 2nd paragraph after end of list: s/"to do"/"to"

- 3.2, 2nd paragraph: Please expand DTN

- 3.2, last paragraph:
The reference to Appendix A is worded in a way that suggests you have to read that section to understand how to implement time scaling factors. That led me to wonder why the appendix was not part of the body. But when I read the appendix, I realized that it really was additional explanation, and not a normative part of the process. Please consider something like the following:

OLD:
For a full description of this process...
NEW:
For additional discussion about this process...

- 3.4.1, first paragraph: The MAY seems like a statement of fact, not a normative requirement. (Same for 3.4.2)

No objection to the publication of this document, but it's important to get Warren's COMMENT addressed:
This document defines a new IPv6 Destination Option. Adding this to a packet pushes the L4 information further out, potentially making it unavailable to the forwarding engine / ACLs. This is not just a theoretical issue - see RFC7872 for real world examples. This means that if I connect to a remote machine and enable this, I may lock myself out of the machine (return packets may not make it back to me); this should be noted (perhaps by expanding on section 1.6).

Agree with the many comments by the other ADs. Especially, Mirja's and Ben's comments, the document reads like a white paper vs. an IETF specification.

The "Consent to be Measured" by a user (section 4.4) seems contra to the use case described in the document (estimate QoS as experienced by an end user device). It should be the network provider who should be giving "consent to be measured" and the associated risks. Warren also noted these sentences as inappropriate. The document discusses the security aspects relative to the user but is missing discussion with respect to the network provider.

I think the description of timing attacks could use a bit more work.
Specifically:

- I am assuming that you should discard rather than using as timestamp
  sources packets which fail ESP. This shouldn't be an issue for
  transport mode because you process ESP first, but in tunnel mode
  you allow either order, so it's a potential issue.

- It seems like you could use this technique for fine-grained
  timing of the cryptographic operations traffic keys as well (cf. Lucky 13),
  not just long-term keys as you say in S 4.4.

Note that both of these attacks are not ameliorated by restricting
to host and ports because one assumes that the attacker controls
the network per 3552.

I support Warren's discuss and comments and have a few additional comments to add.

Kind of related to Warren's discuss, I kept looking for a limitation to the scope for this work in the draft and didn't get to one until the end of the security considerations section.  The text there wasn't quite clear enough for me.  It seems that this might only be used for small periods of time while troubleshooting, is that correct?  It also seems like this has to be end-to-end, is that right?  And if it does need to be end-to-end, is the user aware of this troubleshooting so that they are not sending traffic that contains sensitive data that should remain confidential (security or privacy implications may also exist if this is not the case).

If the scope were limited, I would not have as many security concerns.  Network reconnaissance may or may not be an issue.  I don't think it is, but I need to better understand the scope of use for this option.

nit:
s/IPSec/IPsec/g

Thanks for adding in Tero's suggested text from his SecDir review, his point is important to include.  Please make sure this gets into the approved version.
https://mailarchive.ietf.org/arch/msg/secdir/BAIkONwtaQvH2toiTY76Ic1cakA

My main concern is that part of this document read like an advertisement (e.g. "In our experience, valuable time is often lost.." whose experience? The IETF? This is an IETF RFC!). I think most of this text is not needed to understand the option and therefore should simply be removed. More concretely, I propose to remove sections 1.2, 1.3., and 1.5 as well as paragraphs 4-8 of section 1.4 (starting with "In our experience, valuable time is often lost..." to the end). 

I would also recommend these two changes to shorten the RFC: 
- section 3.2.3. could just be moved into the appendix.
- the diagrams from RFC4303 in sections 3.4.1. and 3.4.2 are not needed
In general I think another editing pass could help to bring the document more to the point in a couple of cases. But that's not really an issue.

Further comments:
1) This text in 3.4.2 is a bit confusing:
"As a completely new IP packet will be made, it means that PDM
   information for that packet does not contain any information from the
   inner packet, i.e. the PDM information will NOT be based on the
   transport layer (TCP, UDP, etc) ports etc in the inner header, but
   will be specific to the ESP flow. 

   If PDM information for the inner packet is desired, the original host
   sending the inner packet needs to put PDM header in the tunneled
   packet, and then the PDM information will be specific for that
   stream."
I think what you want to say is something like
"A tunnel endpoint that creates a new packet may decide to use PDM independent of the use of PDM of the original packet to enable delay measurements between the two tunnel endpoints."
Correct?

2) I'm not sure this is really useful to specify normatively in an RFC as this is really implementation specific:
"The PDM destination options extension header MUST be explicitly
   turned on by each stack on a host node by administrative action. The
   default value of PDM is off."
I would recommend the following text instead (without normative language):
"An implementation should provide an interface to enable or disable the use of PDM.
This specification recommends to turn PDM off by default."

3) I don't understand section 3.6. Isn't that redundant with 3.5.1? Or what's meant by 'dynamic configuration option'? In any case, I don't think the use of normative language is appropriate here.

4) I would also like to propose new text on 3.6 5-tuple Aging (btw. 3.6. exists twice)
OLD
"3.6 5-tuple Aging

   Within the operating system, metrics must be kept on a 5-tuple basis.

   The question comes of when to stop keeping data or restarting the
   numbering for a 5-tuple.  For example, in the case of TCP, at some
   point, the connection will terminate.  Keeping data in control blocks
   forever, will have unfortunate consequences for the operating system.

   So, the recommendation is to use a known aging parameter such as Max
   Segment Lifetime (MSL) as defined in Transmission Control Protocol
   [RFC0793] to reuse or drop the control block.  The choice of aging
   parameter is left up to the implementation."
NEW
"3.6 Information Access and Storage

   Measurement information provided by PDM must be made accessible 
  for higher layers or the user itself. Similar as activating the use of PDM,
the implementation may also provide an interface to indicate if received 
PDM information should be stored or not. If a packet with PDM information
is received and the information should be stored, the upper layers may be 
notified. Further it is recommend to define a configurable 
maximum lifetime after which the information can be removed as well as a
configurable maximum amount of memory that should be allocated for PDM 
information."
This text also addresses some of the "SYN flood attack" concerns as described in the 
security considerations section. I would recommend to rewrite this section as
well and I would also recommend to not use the term SYN flood as that is clearly 
associated with TCP only.

5) Also section 4.1 (security consideration): I don't think this sentence is true:
" For PDM, the amount of data to be kept is quite small. That is, the
   control block is quite lightweight."
Because you eventually have to hold this data per packet, so it can grow quickly. 
However, this is also really an implementation question only. You could also just 
store the delay calculation and not the whole control block, or even an moving
average of the delay which only needs a fixed amount of memory for a few values.
I really depends what your use case is for the information provided by PDM.

Thanks for addressing my DISCUSS points and my comments.