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

[Warren Kumari <[e-mail]>]

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,  <[e-mail]> 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
> [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
>



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