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

From: Warren Kumari <[email-masked]>
Date: Sat, 08 Apr 2017 10:01:22 -0700

Warren Kumari has entered the following ballot position for
draft-ietf-ippm-6man-pdm-option-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

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

---

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

Warren,

Thanks so much!

Will use your words:  "where it is not visible to filtering logic, and may be dropped" 

I believe that was the only change.

I am making all changes in my working copy & will update as one big change.

My plan is to do one set of comments (per AD) per day.   Sorry, I got behind in working through the comments.

Tomorrow, I will be doing Mirja's comments.

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

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

 Subject: Re: [ippm] Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT)
 To: "Nalini Elkins" <[email-masked]>
 Cc: "The IESG" <[email-masked]>, [email-masked], "Bill Cerveny" <[email-masked]>, [email-masked], "MORTON, ALFRED C (AL)" <[email-masked]>, [email-masked]
 Date: Tuesday, April 25, 2017, 10:08 AM
 
 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.
 
 >
 >
 >  > 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
 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.
 
 Great.
 
 >  > 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?
 
 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."
 
 >
 >
 >  > 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 still don't love this, but am OK with
 it.
 
 >  > 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.
 
 WFM.
 
 -----
 
 On
 Tue, Apr 25, 2017 at 10:40 AM,  <[email-masked]>
 wrote:
 > 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.
 >> 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
 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

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