Re: [ippm] Mirja Kühlewind's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT)

<nalini.elkins@insidethestack.com> Fri, 05 May 2017 15:32 UTC

Return-Path: <nalini.elkins@insidethestack.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6570C129A9C for <ippm@ietfa.amsl.com>; Fri, 5 May 2017 08:32:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.409
X-Spam-Level:
X-Spam-Status: No, score=0.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0sp_iUwIwHb for <ippm@ietfa.amsl.com>; Fri, 5 May 2017 08:32:04 -0700 (PDT)
Received: from sonic308-16.consmr.mail.gq1.yahoo.com (sonic308-16.consmr.mail.gq1.yahoo.com [98.137.68.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF6F2129A9B for <ippm@ietf.org>; Fri, 5 May 2017 08:32:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1493998321; bh=+V1VTYxCT3/JIpJ2k0S9qjrSNUeToeGVYcUl46YfscE=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=iEYVbz2yEXZxp1Nr5Kf5Wau6vZNWrbhzn9//Ib2Dg/iJr+FxMsUtfOdoAUYQHiZFoxbBl4m2PXMDJSALRIJ0z5TZwOHZx18qLVbQHtY166uLE31m7SCvW2gYMkKI5aTfZHnD51kE1uByjMugKdrO8dDLGIQGmfrh7gCdDBs2X42TVQXMwmNISQy0gCPjTCFFFx+uIWr0P/vPQFc410LFMZF/rdFBSAVYZSWIFw2d/ApUHKoxoFiGnITnOwRCR7l2QRMTdKMvuDaM0B3WrCda17C8Aba9fPqxzun9kDMCjFXMqXNHLoMGrlrbfdm0vzkrQSv7WMCVexo1LtB57tvc9g==
X-YMail-OSG: eK82bHYVRDtgfAoCqOIpFuQf7CXNzbPmvwqKAF0E6WpCYH8GW8U-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Fri, 5 May 2017 15:32:01 +0000
Date: Fri, 05 May 2017 15:32:00 +0000
From: nalini.elkins@insidethestack.com
Reply-To: nalini.elkins@insidethestack.com
To: Nalini Elkins <nalini.elkins@insidethestack.com>, Warren Kumari <warren@kumari.net>
Cc: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, ippm-chairs@ietf.org, " ALFRED C (AL)MORTON" <acmorton@att.com>, ippm@ietf.org, Bill Cerveny <ietf@wjcerveny.com>, draft-ietf-ippm-6man-pdm-option@ietf.org, The IESG <iesg@ietf.org>
Message-ID: <1069726291.4378413.1493998320896@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
References: <1069726291.4378413.1493998320896.ref@mail.yahoo.com>
X-Mailer: WebService/1.1.9539 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/zL2tDCQN5_UzMQMliDG93C--0M0>
Subject: Re: [ippm] Mirja Kühlewind's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 May 2017 15:32:07 -0000


Thanks, Warren!

I am keeping track of all the changes promised & keeping Spencer / Al / the co-authors updated.

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

--------------------------------------------
On Fri, 5/5/17, Warren Kumari <warren@kumari.net> wrote:

 Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT)
 To: "Nalini Elkins" <nalini.elkins@insidethestack.com>
 Cc: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, ippm-chairs@ietf.org, "MORTON, ALFRED C (AL)" <acmorton@att.com>, ippm@ietf.org, "Bill Cerveny" <ietf@wjcerveny.com>, draft-ietf-ippm-6man-pdm-option@ietf.org, "The IESG" <iesg@ietf.org>
 Date: Friday, May 5, 2017, 8:27 AM
 
 I'm still holding a DISCUSS
 on this - the proposed changes by Nalini
 to
 address my concerns (earlier / in a different thread) are
 fine with
 me and address my concerns.
 Being unfamiliar with the custom (and blindly
 following the text on
 the DISCUSS page)
 I'd originally said that I'd remove my discuss
 once
 a new version was published - but I
 trust Spencer / the authors to
 include the
 promised, and so am clearing my DISCUSS....
 
 Thanks all,
 W
 
 On Fri, May 5, 2017 at
 11:14 AM,  <nalini.elkins@insidethestack.com>
 wrote:
 > Mirja,
 >
 > Thanks for your comments.
 >
 > My replies inline.
 >
 > As stated below, I
 will create a new version with the appendix and the changes
 agreed upon so far.    Then, we can continue.   Thanks so
 much to Spencer and Al for their sage guidance through this
 process.
 >
 >
 Thanks,
 >
 > Nalini
 Elkins
 > CEO and Founder
 > Inside Products, Inc.
 >
 www.insidethestack.com
 > (831)
 659-8360
 >
 >
 --------------------------------------------
 > On Tue, 5/2/17, Mirja Kuehlewind (IETF)
 <ietf@kuehlewind.net>
 wrote:
 >
 >  Subject:
 Re: Mirja Kühlewind's No Objection on
 draft-ietf-ippm-6man-pdm-option-09: (with COMMENT)
 >  To: nalini.elkins@insidethestack.com
 >  Cc: "The IESG" <iesg@ietf.org>,
 draft-ietf-ippm-6man-pdm-option@ietf.org,
 acmorton@att.com,
 "Bill Cerveny" <ietf@wjcerveny.com>,
 ippm-chairs@ietf.org,
 ippm@ietf.org
 >  Date: Tuesday, May 2, 2017, 3:58 AM
 >
 >>>--------------------------------------------
 >>>On Wed, 4/12/17, Mirja Kühlewind
 <ietf@kuehlewind.net>>wrote:
 >>>
 >>>Subject: Mirja Kühlewind's No
 Objection on draft-ietf-ippm-6man-pdm-option-09: (with
 COMMENT)
 >>>To: "The
 IESG" <iesg@ietf.org>
 >>>Cc: draft-ietf-ippm-6man-pdm-option@ietf.org,
 "Al Morton" <acmorton@att.com>,
 "Bill Cerveny" <ietf@wjcerveny.com>,
 ippm-chairs@ietf.org,
 acmorton@att.com,
 ippm@ietf.org
 >>>Date: Wednesday, April 12, 2017,
 10:53 AM
 >>>
 >>>Mirja Kühlewind 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/
 >>>
 >>>
 >>>----------------------------------------------------------------------
 >>>COMMENT:
 >>>----------------------------------------------------------------------
 >>>
 >>>
 >>>>My main concern is that part of
 this document read like an advertisement (e.g. "In our
 experience, valuable time is often lost.." whose
 >>>>experience? The IETF? This is
 an IETF RFC!). I think most of this text is not needed to
 understand the option and therefore should simply be
 >>>>removed. More concretely, I
 propose to remove sections 1.2, 1.3., and 1.5 as well as
 paragraphs 4-8 of section 1.4 (starting with "In our
 >>>>experience, valuable time is
 often lost..." to the end).
 >>>
 >>>I
 think that RFCs are often lacking context which makes them
 difficult for new people or even people not intimately
 involved in the creation
 >>>of the
 draft to understand why they are being written.
 >
 >> I disagree. The
 important part of a protocol spec is that it is well defined
 and to the point, so implementors can easily implement it
 correctly without
 >> having knowledge
 about all the background discussions that happen in the
 working group.
 >
 >
 Sure.
 >
 >
 >>>I am OK with moving the information
 to an appendix.  What do you think?
 >
 >> I don’t think these section actually
 provide information that is useful for implementor but I’m
 okay with moving them to the appendix. I would still
 >> recommend to remove any language on
 business model at least in section 1.2 (or remove at least
 1.2 completely).
 >
 >
 OK.  I will create a new version with a revised appendix
 and then wait for your comments.
 >
 >
 >>>
 >>>One question though, I believe you
 mean "paragraphs 4-8 of section 1.4 (ENDING with
 "In our experience, valuable time is often
 lost...").
 >>>The  phrase
 "In our experience, valuable time is often
 lost..." is the very last sentence of section 1.4.
 >
 >> Yes, sorry. I
 meat starting with "One of the important
 functions“.
 >
 >>
 One important point here about the language is that this
 document seems to be written with the view of a specific
 group. However as RFC
 >> it’s an
 IETF consensus document with represents the IETF’s view as
 a whole. So any phrasing like "In our experience,…“
 or „we can“/„we may“
 >> seems
 not appropriate here and should be removed even if the text
 is moved to the appendix.
 >
 > I will doublecheck that wording and
 remove.
 >
 >
 >>>
 >>>
 >>>>I would also recommend these
 two changes to shorten the RFC:
 >>>>- section 3.2.3. could just be
 moved into the appendix.
 >>>
 >>>Fine.
 >>>
 >>>I will
 move: "3.2.3 Considerations of this time-differential
 representation" into an appendix
 >
 >>>
 >>>>- the diagrams from RFC4303 in
 sections 3.4.1. and 3.4.2 are not needed
 >>>
 >>>OK.
 >>>
 >>>>In
 general I think another editing pass could help to bring the
 document
 >>>>more to the point
 in a couple of cases. But that's not really an issue.
 >>>
 >>>
 >>>>Further comments:
 >>>
 >>>>1)
 This text in 3.4.2 is a bit confusing:
 >>>>"As a completely new IP
 packet will be made, it means that PDM information for that
 packet does not contain any information from the inner
 packet, i.e. the PDM information will NOT be based on the
 >>>>transport layer (TCP, UDP, etc)
 ports etc in the inner header, but will be specific to the
 ESP flow.
 >>>
 >>>> If PDM information for the
 inner packet is desired, the original host sending the inner
 packet needs to put PDM header in the tunneled packet, and
 then the PDM information will be specific for that
 >>>>stream."
 >>>
 >>>>I
 think what you want to say is something like
 >>>
 >>>>"A tunnel endpoint that
 creates a new packet may decide to use PDM independent of
 the use of PDM of the original packet to enable delay
 measurements between the two tunnel endpoints."
 >>>>Correct?
 >>>
 >>>Yes, I
 think your wording represents what I wanted to convey and
 does it better.
 >>>
 >>>
 >>>>2)
 I'm not sure this is really useful to specify
 normatively in an RFC as this is really implementation
 specific:
 >>>>"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."
 >>>>I would recommend the following
 text instead (without normative language):
 >>>>"An implementation should
 provide an interface to enable or disable the use of PDM. 
 This specification recommends to turn PDM off by
 default."
 >>>
 >>>I believe you are speaking of
 section 3.5.1
 >>>
 >>>The reason for this was because an
 implementation could be created which automatically and
 dynamically turned on PDM when a packet containing a PDM
 header was received.  Then, PDM would be used
 >>>without the host being explicitly
 aware of it.  And a number of unfortunate things such as
 information leakage, DOS attacks, etc might happen.  So, we
 added language to say that administrative action is
 required.  This issue was brought up by the security area
 review of this document.
 >>>
 >>>The issue mentioned above is dealt
 with explicitly in section 3.5.1.  The entire text is
 below:
 >>>
 >>>Current text
 >>>----------------
 >>>
 >>>3.5.1
 PDM Activation
 >>>
 >>>   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.
 >>>
 >>>   PDM MUST NOT be turned on
 merely if a packet is received with a PDM header. The
 received packet could be spoofed by another device.
 >
 >
 >> I understand the intention here and
 the intention is correct. My comment was that the use of
 normative language here might not be really appropriate
 because
 >> this part does not talk
 about the protocol itself but the interface to the higher
 layer and this depends very much on the use case and
 environment in which it is
 >>
 implemented. Therefore I would recommend to not use
 normative language here.
 >
 > OK.   Will change.
 >
 >>>
 >>>
 >>>
 >>>>3) I don't understand
 section 3.6. Isn't that redundant with 3.5.1? Or
 what's meant by 'dynamic configuration option'?
 In any case, I don't
 >>>>think the use of normative
 language is appropriate here.
 >>>
 >>>This
 was also brought up by Warren.  He accepted the change
 below.  Please let me know if that also works for you.
 >>>
 >>>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.
 >
 >
 >> Okay.
 >
 >>>
 >>>
 >>>>4)
 I would also like to propose new text on 3.6 5-tuple Aging
 (btw. 3.6. exists twice)
 >>>
 >>>Thanks will fix the 3.6 twice.
 >>>
 >>>>OLD
 >>>
 >>>>"3.6 5-tuple Aging
 >>>
 >>>>Within the operating system,
 metrics must be kept on a 5-tuple basis.
 >>>
 >>>>The question comes of when to
 stop keeping data or restarting the numbering for a
 5-tuple.  For example, in the case of TCP, at some
 >>>> point, the connection will
 terminate.  Keeping data in control blocks forever, will
 have unfortunate consequences for the operating
 >>>>system.
 >>>
 >>>>
 So, the recommendation is to use a known aging parameter
 such as Max Segment Lifetime (MSL) as defined in
 Transmission Control Protocol
 >>>> [RFC0793] to reuse or drop the
 control block.  The choice of aging parameter is left up to
 the implementation."
 >>>
 >>>>NEW
 >>>
 >>>>"3.6 Information Access
 and Storage
 >>>
 >>>>Measurement information
 provided by PDM must be made accessible for higher layers or
 the user itself. Similar as activating the use of
 >>>>PDM, the implementation may
 also provide an interface to indicate if received
 >>>
 >>>>PDM information should be
 stored or not. If a packet with PDM information is received
 and the information should be stored, the upper layers may
 be
 >>>>notified. Further it is
 recommend to define a configurable maximum lifetime after
 which the information can be removed as well as
 >>>>a configurable maximum amount
 of memory that should be allocated for PDM
 information."
 >>>
 >>>>This text also addresses some
 of the "SYN flood attack" concerns as described in
 the security considerations section. I would recommend to
 rewrite this
 >>>>section as well
 and I would also recommend to not use the term SYN flood as
 that is clearly associated with TCP only.
 >>>
 >>>As far
 as:
 >>>
 >>>"Measurement information
 provided by PDM must be made accessible for higher layers or
 the user itself."
 >>>
 >>>The information in PDM is in the
 extension header.  What we had envisioned is that
 diagnostics would be done by capturing a packet trace. 
 But, certainly what
 >>>you suggest
 is very interesting.  Higher layers as well as the user
 could make very good use of PDM information.
 >>>
 >>>Are
 you OK with a minor change to that sentence to say:
 >>>
 >>>"Measurement information
 provided by PDM may be made accessible for higher layers or
 the user itself.“
 >>>
 >
 >> Okay.
 >
 >
 >>>As far as the rest of the text in
 that paragraph, I am fine with it.  In fact, in working on
 implementation, we are doing exactly that:  a configurable
 amount of memory / lifetime.
 >>>Actually, only memory is needed as
 then it controls everything else quite well.    This is
 why we said "limit on control blocks" in the
 security section.  I will make it
 >>>more explicit that what is meant by
 control blocks is memory.
 >>>
 >>>
 >>>Current Security 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.
 >>>
 >>>
 >>>>5) Also section 4.1 (security
 consideration): I don't think this sentence is true:
 >>>>" For PDM, the amount of
 data to be kept is quite small. That is, the control block
 is quite lightweight."
 >>>>Because you eventually have to
 hold this data per packet, so it can grow quickly. 
 However, this is also really an implementation question
 only. You could
 >>>>also just
 store the delay calculation and not the whole control block,
 or even an moving average of the delay which only needs a
 fixed amount of memory for a few
 >>>>values.  I really depends what
 your use case is for the information provided by PDM.
 >>>
 >>>Please
 let me know if the above changes to section 4.1 addresses
 your concerns.
 >
 >>
 Maybe this:
 >
 >>
 OLD:
 >
 >>"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.“
 >
 >> NEW:
 >
 >>„Without a memory limit, 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 could be used to compromise the end
 host.“
 >
 >
 > Fine.
 >
 > Thanks,
 >
 Nalini
 >
 
 
 
 -- 
 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