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

[<[e-mail]>]

Mirja,

I have posted a new draft.   I believe it responds to all your comments and suggestions.  Thanks so much for the care and consideration you took in reviewing.   Please let me know if there is anything more you would like to suggest as improvement.

https://datatracker.ietf.org/doc/html/draft-ietf-ippm-6man-pdm-option-10

Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
[phone]

--------------------------------------------
On Fri, 5/5/17,  <[e-mail]> wrote:

 Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT)
 To: [e-mail], "Mirja Kuehlewind (IETF)" <[e-mail]>
 Cc: "The IESG" <[e-mail]>, [e-mail], [e-mail], "Bill Cerveny" <[e-mail]>, [e-mail], [e-mail]
 Date: Friday, May 5, 2017, 8:14 AM
 
 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
 [phone]
 
 --------------------------------------------
 On Tue, 5/2/17, Mirja Kuehlewind (IETF)
 <[e-mail]>
 wrote:
 
  Subject: Re: Mirja Kühlewind's No
 Objection on draft-ietf-ippm-6man-pdm-option-09: (with
 COMMENT)
  To: [e-mail]
  Cc: "The IESG" <[e-mail]>,
 [e-mail],
 [e-mail],
 "Bill Cerveny" <[e-mail]>,
 [e-mail],
 [e-mail]
  Date: Tuesday, May 2, 2017, 3:58 AM
  
 >>--------------------------------------------
 >>On Wed, 4/12/17, Mirja
 Kühlewind <[e-mail]>>wrote:
 >>
 >>Subject: Mirja Kühlewind's No
 Objection on draft-ietf-ippm-6man-pdm-option-09: (with
 COMMENT)
 >>To: "The IESG" <[e-mail]>
 >>Cc: [e-mail],
 "Al Morton" <[e-mail]>,
 "Bill Cerveny" <[e-mail]>,
 [e-mail],
 [e-mail],
 [e-mail]
 >>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