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

[Magnus Westerlund <[e-mail]>]

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:
> 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 <
> > [e-mail]> escribió:
> > 
> > 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.
> 
> [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?
> 
> > 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.
> 
> [Authors] Correct. RFC 6040 is the proper reference.
> 
> Best Regards.
> 
> 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > I2nsf mailing list
> > [e-mail]
> > 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: [phone] Fax: [phone] e-mail: [e-mail]
> -------------------------------------------------------
> 
> 
> 
>