Subject: [I2nsf] Magnus Westerlund's Discuss on draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: (with DISCUSS)

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Thu, 05 Nov 2020 06:55:29 -0800

Magnus Westerlund has entered the following ballot position for
draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: Discuss

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-i2nsf-sdn-ipsec-flow-protection/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

        leaf ecn {
          type boolean;
          default false;
          description
            "Explicit Congestion Notification (ECN). If true
            copy CE bits to inner header.";
          reference
            "Section 5.1.2 and Appendix C in RFC 4301.";
        }

There is something wrong here, likely in the description of the option. This as
the outer IP header on sender side needs to set ECN field to ECT to enable so
that any CE marks can be received. I think it is reasonable to have an option
to just enable ECN, but that requires several things. Secondly with the changes
in RFC 8311, there might be need to be more explicit in the configuration of
ECN to actually indicate which ECT value that should be set on send side for
the established IPsec tunnel. Due to under discussion experiments with ECT
values per RFC 8311 we should verify that just copying the inner header value
to the external is fine and don't break anything as path and/or marking
behavior may not be the same.

I think there is also the question if RFC 6040 needs to be referenced in this
context to ensure that people pick up on that RFC 6040 updates RFC 4301.

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Mon, 23 Nov 2020 19:19:24 +0100

Dear Magnus:

Thank you very much for your review. Please, see our comments below.

> El 5 nov 2020, a las 15:55, Magnus Westerlund via Datatracker <[email-masked]> escribió:
> 

[Authors] Yes, we agree with you that this is poorly explained and needs to be clarified.

On the one hand, RFC 6040 mentions:

"Modes:  RFC 4301 tunnel endpoints do not need modes and are not
updated by the modes in the present specification.  Effectively,
an  RFC 4301 IPsec ingress solely uses the REQUIRED normal mode of
encapsulation, which is unchanged from RFC 4301 encapsulation. 
It will never need the OPTIONAL compatibility mode as explained 
in Section 4.3”.

Therefore, our interpretation is that for RFC 4301 tunnels we can only apply 
Figure 3 ("Normal mode” column), which means copying the values of inner header to outer header.

On the other hand, regarding your comment about RFC 8311, our interpretation is that only specifying copy would be not enough for certain cases based on RFC 8311 so there might be a need to set an ECT(0) or ECT(1) when the inner packet could be ECT(0) or ECT(1) but copying is not valid. For example, if the inner packet has ECT(0) or ECT(1) but we want to set the outer IP header with ECT(0) for either case. Is this interpretation correct? If it is, we think we could accommodate this as:

container ecn {
       leaf copy-or-set { 
         type boolean;
         default true; 
         description 
           "If True the ECN field of the incoming IP header
           is copied to the outer IP header of the tunnel following
           RFC 6040 normal mode. If False, it is possible to set
           a specific ECT value (ECT (0) or ECT (1) to the outer
           header of the tunnel.";
         reference 
           "RFC 6040. RFC 8311.";
       }
       leaf set {
         when "../copy-or-set = 'true'";
                 
         type enumeration {         
           enum ect0 {
             value 0;
             description 
               "ECT(0)";
           }
           enum ect1 {
             value 1; 
             description 
               "ECT(1)";
           }
         }
         description 
           "To set an specific ECT value in the 
           outer IP header when the inner IP header contains ECT(0)
           or ECT(1) value.";
         reference 
           "RFC 8311";
       }
       description 
         "Explicit Congestion Notification (ECN) management.";
       reference 
         "RFC 6040. RFC 8311";
     } 

Does this reflect what you had in mind?

> context to ensure that people pick up on that RFC 6040 updates RFC 4301.

[Authors] Correct. RFC 6040 is the proper reference.

Best Regards.

> 
> 
> 
> 
> 
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 25 Nov 2020 14:48:47 +0000

Hi,

Thanks for clarification of this issue. I will have to reach out to some of the
people that are the true experts on this and see what they do respond. I will
come back to you within a week. If not please ping me. 

Thanks

Magnus

On Mon, 2020-11-23 at 19:19 +0100, Rafa Marin-Lopez wrote:
> On the other hand, regarding your comment about RFC 8311, our interpretation
> is that only specifying copy would be not enough for certain cases based on
> RFC 8311 so there might be a need to set an ECT(0) or ECT(1) when the inner
> packet could be ECT(0) or ECT(1) but copying is not valid. For example, if the
> inner packet has ECT(0) or ECT(1) but we want to set the outer IP header with
> ECT(0) for either case. Is this interpretation correct? If it is, we think we
> could accommodate this as:
> 
> container ecn {
>        leaf copy-or-set { 
>          type boolean;
>          default true; 
>          description

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 27 Nov 2020 08:56:25 +0000

Hi,

Please see below. 

On Wed, 2020-11-25 at 14:48 +0000, Magnus Westerlund wrote:
> > > There is something wrong here, likely in the description of the option.
> > > This
> > > as
> > [Authors] Yes, we agree with you that this is poorly explained and needs to
> > be
> > clarified.
> > 

Sorry, I think I lead you astray due to no understanding the context here
sufficiently. So as long as the option is to turn on "Normal Mode" for tunnel
processing of the ECN bits or not then you can disregard the whole thing about
RFC 8311. The applications that will use alternative behaviors for ECN will have
to know that the consumer understand the semantics. So in this case as the IPSec
tunnel only copies the bits back and forth no additional action is needed. 

So please remove the whole second sentence and the RFC8311 reference.

In addition to the first part of the below description. It only mentions the
encapsulation action. So my quesiton, is this configuration only for the
encapsulating entity, or for a whole tunnel and applied to both ends? If it is
the later, then I think you should take note of the need to process the outer
ECN field and remark per RFC6040. 

Cheers

Magnus