Re: [ippm] Ben Campbell's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT)

[<[e-mail]>]

--------------------------------------------
On Wed, 4/12/17, Ben Campbell <[e-mail]> wrote:

 Subject: [ippm] Ben Campbell's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT)
 To: "The IESG" <[e-mail]>
 Cc: [e-mail], "Bill Cerveny" <[e-mail]>, [e-mail], [e-mail], [e-mail]
 Date: Wednesday, April 12, 2017, 1:26 PM
 
 > Ben Campbell has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09: No Objection
 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions.

>  The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/
 
 Ben Campbell

>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?


I believe that you are referring to this:

"What PDM will tell you is whether the problem is in the network or
the server. In our experience, there is often a different group which
is involved to troubleshoot the problem depending on the nature of
the problem.   That is, the problem may be escalated to the
application developers or the team that deals with the routers and
infrastructure.  Both the network group and the application group
have quite a few specialized tools at their disposal to further
investigate their own areas.   What is missing is the first step,
which PDM provides."

Certainly organizations do this differently.   That is why I said:

"In our experience, there is often a different group"

I can say:

"In some organizations, there may be a different group"

if you prefer that wording.

But for any group doing troubleshooting (after having done quite
a bit of it myself!), the need to isolate at every level is critical.
The first level being network and host.


> - 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?

True.  That wording came about because initially there was confusion as
to whether PDM would by itself provide all the data needed.   So, that
paragraph continues to explain that PDM variables are used in 
conjunction with other variables from other headers.  I can reword
as follows.

Current
-------
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.   The way PDM would be used is by a technician
(or tool) looking at a packet capture. 


New
---
PDM may be used in conjunction with variables in other headers.
For example, if PDM may be used by a technician (or tool) looking 
at a packet capture. 


>3.2.1, PSNTP definition:

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

The consequences would be that the measurements would likely be
wrong.   We have taken care that a resource consumption attack
would not happen.  That is, that if a host receives a packet with
a PDM extension, that it would not automatically respond by
starting to collect PDM data.   This is why we have PDM started
by administrative action only.


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

We were trying to future-proof.   I know Wireshark is looking at
nanosecond precision, if they don't have it already.   I have 
customers with single digit microsecond for network time already.
In discussions with previous reviewers, we settled on 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?

I assume you are talking about this statement:

"We recommend that implementation of PDM SHOULD have a limit on the
number of control block entries."

That section has been redone per Mirja's comments.   Please let me
know if you agree.

The essence of Mirja's discussion in this area was that using control 
blocks was merely one potential implementation.  It is really memory
which is of concern.  I agree with Mirja's point.

So, the statement has been changed to:

"A limit on how much memory is being used SHOULD be implemented."

Having said all this, I do not feel comfortable about indicating
a hard limit.  This is very implementation dependent.  They may 
choose to have a running total, average, etc.

Current section
---------------

4.1. SYN Flood and Resource Consumption Attacks

   PDM needs to calculate the deltas for time and keep track of the
   sequence numbers. This means that control blocks must be kept at the
   end hosts per 5-tuple.   Any time a control block is kept, an
   attacker can try to mis-use the control blocks such that there is a
   compromise of the end host.

   PDM is used only at the end hosts and the control blocks are only
   kept at the end host and not at routers or middle boxes.   Remember,
   PDM is an implementation of the Destination Option extension header.
   
   A "SYN flood" type of attack succeeds because a TCP SYN packet is
   small but it causes the end host to start creating a place holder for
   the session such that quite a bit of control block and other storage
   is used.   This is an asynchronous type of attack in that a small
   amount of work by the attacker creates a large amount of work by the
   resource attacked.

   For PDM, the amount of data to be kept is quite small. That is, the
   control block is quite lightweight.  Concerns about SYN Flood and
   other type of resource consumption attacks (memory, processing power,
   etc) can be alleviated by having a limit on the number of control
   block entries.

   We recommend that implementation of PDM SHOULD have a limit on the
   number of control block entries.    

NEW
-------
4.1. Resource Consumption and Resource Consumption Attacks

   PDM needs to calculate the deltas for time and keep track of the
   sequence numbers. This means that control blocks which reside
   in memory may be kept at the end hosts per 5-tuple.   

   A limit on how much memory is being used SHOULD be 
   implemented.

   Additionally, any time a control block is kept in memory, an attacker
   can try to mis-use the control blocks to cause excessive resource
   consumption.   This may create compromise of the end host.

   PDM is used only at the end hosts and the control blocks are only
   kept at the end host and not at routers or middle boxes.  PDM is an 
   implementation of the Destination Option extension header.
       

>-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.

I believe what you are talking about is the statement:

"As far as deducing the content of the payload, it appears to us that
PDM is quite unhelpful in this regard."

No, one could not differentiate between wire-time and processing-time from
observation alone.  Indeed, that is the very reason for the existence
of PDM.

Let's take this one at a time.   As far as network topology, one could probably
deduce some level of network topology.  It would be in the nature of is this
likely to be a LAN, fiber link, or slow horrible link.   But, I may already
be able to tell that from the L2 information in the packet trace 
combined with the address.

That is, if I know from L2 that it is a VM and then I know from the IP
address that it is a 192.168 address, then I already know quite a bit
about the connection.   This is all without using PDM.  So, then with
PDM, I know if the LAN is fast or slow.  That is the reason for PDM.

If it is a global address, then I may have some idea of the network 
topology in terms of possibly number of hops or route length or how
fast the links are.  But, I already have TTL available to me to make
some guesses in that area.

Again, I believe for network topology, I think link speed is likely what
one could deduce from PDM - which is its stated purpose.

As far as being able to deduce the type of application, I can deduce
many things from the traffic pattern alone.   If it is all one-way
traffic, it is likely to be an FTP and so forth.

Of course, PDM adds the timing component which is key additional information.
What we meant is that PDM does not tell you which HTTPS page is being
requested or the user password, etc.

Please let me know what you think of the following change:

Current
-------
As far as deducing the content of the payload, it appears to us that
PDM is quite unhelpful in this regard.

New
-------
As far as deducing the content of the payload, in terms of the application
level information such as web page, user name, user password and so on,
it appears to us that PDM is quite unhelpful in this regard.  Having
said that, the ability to separate wire-time from processing time
may potentially provide an attacker with additional information.


> -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?

Good point.

Current 
-------
For example, if an attacker is able to create an attack which causes the
enterprise to turn on PDM to diagnose the attack, then the attacker
might use PDM during that debugging time to launch a timing attack...

New 
-------
For example, if an attacker can see that PDM is being used, then the 
attacker might use PDM to launch a timing attack...


>-- 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.

True.

Current
-------
So, if with PDM, we recommend that the user SHOULD consent to its use.

New
---
So, if with PDM, we recommend that the user consent SHOULD be required.


> 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?

We have added the folllowing because of comments made by Warren:

"The actual content of "Consent to be Measured" will differ by site but it 
SHOULD make clear that the traffic is being measured for quality of service
and to assist in diagnostics as well as to make clear that there may be potential 
risks of certain vulnerabilities if the traffic is captured during a diagnostic 
session. "

As far as your comment on whether an average user can make an informed decision,
frankly, I have thought for many years that it seems quite unimaginable
that users can actually deal with PCs, cell phones or actually any of it!
Most of my non-technology friends have no idea how much of anything works.

It is like me with cars.  I can drive (usually!) but have zero idea of what to
do when anything goes wrong.   I suppose that boat sailed a long time ago with
technology.  But, here we are.  Meaning, technology that people don't understand
is in everyone's hands and home.  I don't know how much the average
user actually understands about any of it.  Having said that, I can add the following:

"The "Consent to be Measured" SHOULD be written in language that is
understandable to an average user."



>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.

Please see my response to comments from Mirja.  A number of the sections
are being moved to an Appendix or left out.

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

Current
-------
An implementation of the existing IPv6 Destination Options extension
header, the Performance and Diagnostic Metrics (PDM) Destination
Options extension header as well as the field limits, calculations,
and usage of the PDM in measurement are included in this document.

New
---
The field limits, calculations, and usage in measurement of the
Performance and Diagnostic Metrics (PDM) Destination Options extension header
are included in this document.


> - 1.4, list of advantages: How is 5 different than 2?

Good point.

Current
-------
1. Real measure of actual transactions. 

2. Independence from transport layer protocols. 

3. Ability to span organizational boundaries with consistent
   instrumentation.

4. No time synchronization needed between session partners 

5. Ability to handle all transport protocols (TCP, UDP, SCTP, etc) in
   a uniform way 

New
---
 
1. Real measure of actual transactions.  

2. Ability to span organizational boundaries with consistent
   instrumentation.

3. No time synchronization needed between session partners 

4. Ability to handle all transport protocols (TCP, UDP, SCTP, etc) in
   a uniform way 


> -- 2nd paragraph after end of list: s/"to do"/"to"

Current 
-------
One of the important functions of PDM is to allow you to do quickly
dispatch the right set of diagnosticians.

New 
---
One of the important functions of PDM is to allow you to quickly
dispatch the right set of diagnosticians.


> - 3.2, 2nd paragraph: Please expand DTN

Current
-------
 .. and time differentials in a DTN-type environment ...

New
----
 .. and time differentials in a Delay/Disruption Tolerant Networking (DTN)
 environment ...

>- 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...

Fine.



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

Current
-------
Note that Destination Options MAY be placed before or after ESP or both.

New
---
Note that Destination Options may be placed before or after ESP or both.

Same change will be made for section 3.4.2.