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

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 2 May 2017 12:58:04 +0200

Hi Nalini,

sorry for my late reply. See below.

> Am 26.04.2017 um 18:36 schrieb [email-masked]:
> 
> Mirja,
> 
> Thanks for your comments.   Please find my responses inline.
> 
> 
> Nalini Elkins
> CEO and Founder
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-8360
> 
> --------------------------------------------
> On Wed, 4/12/17, Mirja Kühlewind <[email-masked]> wrote:
> 
> Subject: Mirja Kühlewind's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT)
> To: "The IESG" <[email-masked]>
> Cc: [email-masked], "Al Morton" <[email-masked]>, "Bill Cerveny" <[email-masked]>, [email-masked], [email-masked], [email-masked]
> 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.

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

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

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

Thanks,
Mirja

---

From: <[email-masked]>
Date: Fri, 5 May 2017 15:32:00 +0000 (UTC)

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 <[email-masked]> wrote:

 Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT)
 To: "Nalini Elkins" <[email-masked]>
 Cc: "Mirja Kuehlewind (IETF)" <[email-masked]>, [email-masked], "MORTON, ALFRED C (AL)" <[email-masked]>, [email-masked], "Bill Cerveny" <[email-masked]>, [email-masked], "The IESG" <[email-masked]>
 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,  <[email-masked]>
 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
 www.insidethestack.com
 > (831)
 659-8360
 > On Tue, 5/2/17, Mirja Kuehlewind (IETF)
 <[email-masked]>
 wrote:
 >  Subject:
 Re: Mirja Kühlewind's No Objection on
 draft-ietf-ippm-6man-pdm-option-09: (with COMMENT)
 >  To: [email-masked]
 >  Cc: "The IESG" <[email-masked]>,
 [email-masked],
 [email-masked],
 "Bill Cerveny" <[email-masked]>,
 [email-masked],
 [email-masked]
 >  Date: Tuesday, May 2, 2017, 3:58 AM
 >
 >>>On Wed, 4/12/17, Mirja Kühlewind
 <[email-masked]>>wrote:
 >>>
 >>>Subject: Mirja Kühlewind's No
 Objection on draft-ietf-ippm-6man-pdm-option-09: (with
 COMMENT)
 >>>To: "The
 IESG" <[email-masked]>
 >>>Cc: [email-masked],
 "Al Morton" <[email-masked]>,
 "Bill Cerveny" <[email-masked]>,
 [email-masked],
 [email-masked],
 [email-masked]
 >>>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/
 >>>>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
 >>>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 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 will
 move: "3.2.3 Considerations of this time-differential
 representation" into an appendix
 >>>>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.
 >>>>"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
 >>>>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."
 >>>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."
 >>>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:
 >>>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
 >>>This
 was also brought up by Warren.  He accepted the change
 below.  Please let me know if that also works for you.
 >>>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
 >>>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
 >>>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
 >>>>4)
 I would also like to propose new text on 3.6 5-tuple Aging
 (btw. 3.6. exists twice)
 >>>>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."
 >>>>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
 >>>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
 >>> 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
 >>> 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.
 >>> control block is quite
 lightweight.  Concerns about SYN Flood and
 block entries.
 >>> PDM needs to calculate the deltas
 for time and keep track of the
 sequence numbers. This means that control blocks which
 reside
 implemented.
 >>> 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:
 >>„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.“
 > 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

---

From: <[email-masked]>
Date: Tue, 9 May 2017 16:10:27 +0000 (UTC)

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
(831) 659-8360

--------------------------------------------
On Fri, 5/5/17,  <[email-masked]> wrote:

 Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-ippm-6man-pdm-option-09: (with COMMENT)
 To: [email-masked], "Mirja Kuehlewind (IETF)" <[email-masked]>
 Cc: "The IESG" <[email-masked]>, [email-masked], [email-masked], "Bill Cerveny" <[email-masked]>, [email-masked], [email-masked]
 Date: Friday, May 5, 2017, 8:14 AM
 
 Mirja,

 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

  Subject: Re: Mirja Kühlewind's No
  
 >>On Wed, 4/12/17, Mirja
 >>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
 >>
 >>
 >>The document, along with other
 ballot positions, can be found here:  https://datatracker.ietf.org/doc/draft-ietf-ippm-6man-pdm-option/
 >>>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
 >>I think that RFCs are often
 lacking context which makes them difficult for new people or
 even people not intimately involved in the creation
 
 > 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. 

 > 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 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.
 >>>transport layer (TCP, UDP,
 etc) ports etc in the inner header, but will be specific to
 the ESP flow. 
 >>>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
 >>>"An implementation should
 provide an interface to enable or disable the use of
 PDM.  This specification recommends to turn PDM off by
 default."
 >>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:
 >>   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
 >>This was also brought up by
 Warren.  He accepted the change below.  Please let
 me know if that also works for you.
 >>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

 >>>4) I would also like to
 propose new text on 3.6 5-tuple Aging (btw. 3.6. exists
 twice)
 >>>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."
 >>>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.
 >>
 >>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.    

 >>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
 >> small but it causes the end
 host to start creating a place holder for
 >> is used.  This is an
 asynchronous type of attack in that a small
 >> other type of resource
 consumption attacks (memory, processing power,
 >> We recommend that
 implementation of PDM SHOULD have a limit on the
 >> Additionally, any time a
 >>>5) Also section 4.1
 (security consideration): I don't think this sentence is
 >>>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.

 

 >„Without a memory limit, any time
 a control block is kept in memory, an attacker

 Fine.
 
 Thanks,
 Nalini

---

From: <[email-masked]>
Date: Tue, 9 May 2017 16:11:57 +0000 (UTC)

Warren,

I have posted a new draft.   I believe it responds to all your comments as well as the DISCUSS.   Wonderful to have all your thoughtful comments which have greatly improved the document.   Please let me know if there is anything else.

Thanks,

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

 
 
 Thanks all,
 W
 
 On Fri, May 5, 2017 at
 Thanks,
 Elkins
 www.insidethestack.com
 659-8360
 <[email-masked]>
 Sure.
 remove.
 PDM Activation
 >>>Current text
 Dynamic Configuration Options
 Filtering of PDM
 attacked.
 block entries.
 implemented.
 Maybe this:
 Nalini