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

From: <[email-masked]>
Date: Sat, 8 Apr 2017 17:43:42 +0000 (UTC)

Warren,

Thanks for your comments.  I will respond to the comments section ASAP.

 But, this is for the DISCUSS

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

What we meant to say is that the entire Destination Option is optional, not that the packet sequence numbers are optional.

Current wording
---------------------
Abstract

   To assess performance problems,  measurements based on optional
   sequence numbers and timing may be embedded in each packet.  Such
   measurements may be interpreted in real-time or after the fact. 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.

Proposed wording
------------------------

Abstract

   To assess performance problems,  measurements based on 
   sequence numbers and timing may be embedded in each packet.  Such
   measurements may be interpreted in real-time or after the fact. 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.
   The use of the PDM Destination Option is optional.   That is, an implementation
   may choose not to support it.

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
 
 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: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 8 Apr 2017 17:51:59 +0000

Hi Nalini and Warren,
(doc shepherd chiming-in)

Perhaps:
Abstract

   To assess performance problems,  this document describes optional
   headers embedded in each packet that provide sequence numbers and timestamps 
   as a basis for measurements.
   ...

Al

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Saturday, April 08, 2017 1:44 PM
> To: The IESG; Warren Kumari
> Cc: [email-masked]; MORTON, ALFRED C (AL);
> Bill Cerveny; [email-masked]; [email-masked]
> Subject: Re: Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-
> 09: (with DISCUSS and COMMENT)
> 
> Warren,
> 
> > 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
> What we meant to say is that the entire Destination Option is optional,
> not that the packet sequence numbers are optional.
> 
> Current wording
> ---------------------
> Abstract
> 
>  Cc: [email-masked], "Al Morton"
> <[email-masked]>, "Bill Cerveny" <[email-masked]>, ippm-
> [email-masked], [email-masked], [email-masked]
>  Please refer to https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwIFaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=De_5hrtDljLJ3VK66tjLHiANTN9
> K7XMPe5kXd0FjUcU&s=d8aytJtECiLj4P1KOB1q5ORq2jEapXFca8_c6YatAnw&e=
>  https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2D6man-2Dpdm-
> 2Doption_&d=DwIFaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=De_5hrtDljLJ3VK66tjLHiANTN9
> K7XMPe5kXd0FjUcU&s=4Wpy1AmRHeyuVk_zDbqENoerkIYf2AxQTHqp1eTejcI&e=
> 
> 
>

---

From: Warren Kumari <[email-masked]>
Date: Tue, 11 Apr 2017 17:59:28 -0400

>    as a basis for measurements.

I prefer Al's text, but either is fine with me.
The discuss also said:
"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."
For example, when I send my first packet with PDM in it (Section B.1.1
Step 1) I have not yet received any packets with a sequence number, so
I don't know what to put in the PSNLR  field -- I think that this need
to be specified (perhaps 0? 0xFFFF?)

W

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