Subject: Re: [ippm] Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT)

From: <[email-masked]>
Date: Tue, 25 Apr 2017 14:40:07 +0000 (UTC)

Warren,

You may have missed my response to your comments in all the emails going back and forth.

I am resending.    Please let me know what you think.

Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

--------------------------------------------
Warren,

I am responding to your Comments below.

Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

--------------------------------------------
On Sat, 4/8/17, Warren Kumari <[email-masked]>
wrote:

  Subject: Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT)
  To: "The IESG" <[email-masked]>
  Cc: [email-masked], "Al Morton" <[email-masked]>,  "Bill Cerveny" <[email-masked]>,  [email-masked],  [email-masked],  [email-masked]

  Date: Saturday, April 8, 2017, 10:01  AM
  
  > Warren Kumari has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09: Discuss
  
> 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/

----------------------------------------------------------------------
  > DISCUSS:
----------------------------------------------------------------------
  
> The document says that packet sequence number are optional ("measurements based on optional sequence numbers and timing may be embedded in each
> packet"), but doesn't say what should be put in the PSNTP field if I'm not using them. It also doesn't say what I should put in the PSNLR field if I haven't received any PDM packets
> (the exmaple just has a dash).  This means that I cannot create an interoperable implementation from this document alone.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
  
> 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).

How is this?

Current Text
----------------

1.6 IPv6 Transition Technologies

   In the path to full implementation of IPv6, transition technologies such as translation or tunneling may be employed.   The PDM header is not expected to work in such scenarios.  It is likely that an
    IPv6 packet containing PDM will be dropped if using IPv6 transition technologies.

New Text
------------

1.6 Full Support of IPv6 Functionality

   In the path to full implementation of native IPv6, transition technologies such as translation or tunneling may be employed.   The PDM header may not work in such scenarios.  It is likely that an
    IPv6 packet containing PDM will be dropped if using IPv6 transition technologies.

   It is also possible that some devices in the network may not correctly handle multiple IPv6 Extension Headers, including the IPv6 Destination Option.   For example, adding the PDM header to a packet
   may push the layer 4 information to a point in the packet where it is not routed correctly.   This kind of situation is expected to become rare over time.

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

How about if we add the following to Appendix C after the first paragraph:

As with other diagnostic tools, such as packet traces, a certain amount of processing time will be required to create and process PDM.  Since PDM is lightweight (has only a few variables), we expect the processing time to be minimal.

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

I think what we were thinking is that there may be, in the future, middle boxes (for example, firewalls) which might be able to detect nonsensical sequence numbers.   So, they would not be the ones who
initiated the use of PDM as a covert channel.   Is there a better way to say this?

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

The addition "Consent to be Measured"  is so that people know that along with the many benefits of accurate measurements, there are some inevitable small risks.

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

How about if we add something to explain further "Consent to be Measured".   Sentence below:

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

> 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 that paragraph is confusing.   I suggest deleting it since section 3.5.1 already discusses defaults.   

Current text
----------------

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.

   If the PDM destination options extension header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP
   address only.  These are at the discretion of the implementation.

New text
-----------

3.6 Filtering of PDM

   If the PDM destination options extension header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP
   address only.  These are at the discretion of the implementation.

Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

---

From: Warren Kumari <[email-masked]>
Date: Tue, 25 Apr 2017 13:08:07 -0400

Ah, I was wondering why y'all hadn't updated the draft -- I actually
drafted (and then abandoned) an email asking this morning.

I did respond to the original, on April 12th - perhaps it got lost / eaten?

Copied and pasted below:

-------

Warren Kumari <[email-masked]>
Apr 12 (13 days ago)
to Nalini, ALFRED, IESG, draft-ietf-ipp., Bill, ippm-chairs, ippm

Mostly good -- I think that "where is it not routed correctly" seems a
little odd - that feels like it means the packet may be routed to the
wrong place - perhaps "where it is not visible to filtering logic, and
may be dropped" ?
Otherwise good.

> As with other diagnostic tools, such as packet traces, a certain amount of processing time will be required to create and process PDM.   Since PDM is lightweight (has only a few variables), we expe…

Great.

>  initiated the use of PDM as a covert channel.   Is there a better way to say this?

Yeah, that was not clear to me from the text -- it would then also not
be the implementation which would stop using PDM, it would be the
middle box which would (presumably) block it. Perhaps say something
like:
If a PDM aware middle box detects some number of "nonsensical"
sequence numbers it could take action to block (or alert on) this
traffic."

>  may be potential risks of certain vulnerabilities if the traffic is captured during a diagnostic session. "

I still don't love this, but am OK with it.

>   I agree that paragraph is confusing.   I suggest deleting it since section 3.5.1 already discusses defaults.

WFM.

-----

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf