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

From: <[email-masked]>
Date: Tue, 11 Apr 2017 23:36:22 +0000 (UTC)

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

 Subject: Re: Warren Kumari's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT)
 To: "MORTON, ALFRED C (AL)" <[email-masked]>
 Cc: "[email-masked]" <[email-masked]>, "The IESG" <[email-masked]>, "[email-masked]" <[email-masked]>, "Bill Cerveny" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
 Date: Tuesday, April 11, 2017, 2:59 PM
 
 On Sat, Apr 8, 2017 at 1:51 PM,
 MORTON, ALFRED C (AL) <[email-masked]>
 wrote:
>> 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.
>>    ...
 
> I prefer Al's text, but either is fine with me.

I prefer Al's text also but with a minor change.   Timestamps are not sent but rather deltas.   So, the new sentence is:

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

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

Yes.   In section 3.2.1 (PDM Layout)

Existing Text
------------------

  Packet Sequence Number Last Received (PSNLR)

   16-bit unsigned integer.  This is the PSNTP of the packet last received on the 5-tuple.

Add
-----
   This field is initialized to 0.

Thanks,
Nalini

 >
 > 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,
 >>
 >> 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]>,
 ippm-
 >> [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://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=
 >>  for more information about IESG
 DISCUSS
 >>  and COMMENT positions.
 >>
 >>
 >>  The document, along with other
 ballot
 >>  positions, can be found
 here:
 >>  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=
 ----------------------------------------------------------------------
 >>  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...

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

---

From: Warren Kumari <[email-masked]>
Date: Wed, 12 Apr 2017 16:35:31 -0400

Okey dokey.
I'm happy to clear my DISCUSS once a new revision is published.

(I'm new here and the DISCUSS page says: "If revisions are required,
it is customary for the Area Director to clear their DISCUSS only when
the revision containing the necessary emendations has been published
in the Internet-Drafts repository." )

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