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

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 12 Apr 2017 10:53:35 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-ippm-6man-pdm-option-09: No Objection

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://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 would also recommend these two changes to shorten the RFC: 
- section 3.2.3. could just be moved into the appendix.
- the diagrams from RFC4303 in sections 3.4.1. and 3.4.2 are not needed
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?

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

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.

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

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.

---

From: <[email-masked]>
Date: Wed, 26 Apr 2017 16:36:01 +0000 (UTC)

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/

> 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 am OK with moving the information to an appendix.  What do you think?

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. 

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

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

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

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

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.

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

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

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

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.