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 < > > [email protected]> 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 > > [email protected] > > 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 protected] > ------------------------------------------------------- > > > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
