Dear Erik: This e-mail is just to confirm that you received our answer regarding your review.
Best Regards and thanks again. > Inicio del mensaje reenviado: > > De: Rafa Marin-Lopez <[email protected]> > Asunto: Re: [I2nsf] Erik Kline's Discuss on > draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: (with DISCUSS and COMMENT) > Fecha: 3 de noviembre de 2020, 13:05:32 CET > Para: Erik Kline <[email protected]> > Cc: Rafa Marin-Lopez <[email protected]>, The IESG <[email protected]>, [email protected], > [email protected], Yoav Nir > <[email protected]>, [email protected] > > Dear Erik: > > First of all, thank you very much for your comments. Please see ours inline. > >> El 2 nov 2020, a las 8:35, Erik Kline via Datatracker <[email protected] >> <mailto:[email protected]>> escribió: >> >> Erik Kline 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 >> <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/ >> <https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/> >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> general ] >> >> * Similar to df-bit and ecn, should there be a tunnel-grouping leaf that >> controls how inner DSCP marking should be reflected on the outer IPsec >> header? (RFC 2983 suggests using multiple tunnels instead and warns about >> the danger of packet reordering as a result of variable DSCP marking (as >> well as the potential information leak as a security issue), so maybe this >> isn't important. > > First of all, we would like to highlight that in order to model IPsec SPD and > SAD we have used mainly the RFC 4301, in particular, section 4.4.1 for SPD > and section 4.4.2 for SAD. The corresponding Appendix C has been used as > help. > > Regarding the tunnel-grouping, we already had: > > +--rw tunnel > | | +--rw local inet:ip-address > | | +--rw remote inet:ip-address > | | +--rw df-bit? enumeration > | | +--rw bypass-dscp? boolean > | | +--rw dscp-mapping* inet:dscp > | | +--rw ecn? boolean > > In fact, ASN1 in RFC 4301 (Appendix C) also refers to this information. > > For example bypass-dscp controls how DSCP is reflected on the outer IPsec > header (see more comments below related to your question about bypass-dscp). > >> >> Separately, what about a setting to explicitly configure the DSCP mark on >> the outer header for all encap'd packets? > > Yes, that is reasonable (see our comments below). > >> >> [ appendix A ] >> >> * I'm unclear on what bypass-dscp=true means. Does it mean that the DSCP >> value is *not* part of the traffic selector? > > After your comment, we agree that this is a bit confusing. This value has > been extracted from RFC 4301. More specifically: > > SPD entry: > > - Bypass DSCP (T/F) or map to unprotected DSCP values > (array) if needed to restrict bypass of DSCP values -- > applicable to tunnel mode SAs > > Same appears for a SAD entry (but with a more extended explanation) > > Bypass DSCP (T/F) or map to unprotected DSCP values (array) if > needed to restrict bypass of DSCP values -- applicable to tunnel > mode SAs. This feature maps DSCP values from an inner header to > values in an outer header, e.g., to address covert channel > signaling concerns. > > Moreover we have in Appendix C: > > DSCP ::= SEQUENCE { > copy BOOLEAN, -- TRUE copy from inner header > -- FALSE do not copy > mapping OCTET STRING OPTIONAL} -- points to table > -- if no copy > > We believe this description of bypass-dscp would be more accurate to avoid > any confusion in the following way: > > leaf bypass-dscp { > type boolean; > default true; > description > "If True, to copy the DSCP value from inner header > to outer header. If False, to map DSCP values > from an inner header to values in an outer header > following a mapping in ../dscp-mapping"; > reference > "Section 4.4.1.2. in RFC 4301."; > } > > Moreover the dscp-mapping could be improved to include your suggestion > regarding to have a setting for the outer header DSCP marking. This would > also simplify the model so that we may remove spd-mark container (which is > implementation specific - XFRM) to implement the concept of mapping. We can > also include the must you suggested below. > > list dscp-mapping { > must '../bypass-dscp = "false"'; > key id; > ordered-by user; > leaf id { > type uint8; > description > "The index of the list with the > different mappings."; > } > > leaf inner-dscp { > type inet:dscp; > description > "The DSCP value of the inner IP packet. If this > leaf is not defined it means ANY inner DSCP value"; > } > leaf outer-dscp { > type inet:dscp; > default 0; > description > "The DSCP value for the outer IP packet. The default > value is 0 - Best Effort (BE)."; > } > description > "A list that represents an array with the > mapping from the inner DSCP value to outer > DSCP value when bypass-dscp is False"; > reference > "Section 4.4.1.2. and Appendix C in RFC 4301."; > } > > In relation with this discussion, from Section 4.4.2.1 we should model the > following in the ietf-i2nsf-ikeless: > > DSCP values -- the set of DSCP values allowed for packets carried > over this SA. If no values are specified, no DSCP-specific > filtering is applied. If one or more values are specified, these > are used to select one SA among several that match the traffic > selectors for an outbound packet. Note that these values are NOT > checked against inbound traffic arriving on the SA. > > as > > container sad { > … > > container tunnel { > when "../mode = 'tunnel'"; > uses nsfikec:tunnel-grouping; > leaf-list dscp-values { > type inet:dscp; > description > "DSCP values allowed for packets carried over > this IPsec SA. If no values are specified, no > DSCP-specific filtering is applied"; > reference > "Section 4.4.2.1. in RFC 4301."; > } > description > "Endpoints of the IPsec tunnel."; > } > > Does it sound reasonable and clearer? Obviously, we are trying to reflect > what we saw and understand from RFC 4301. > >> >> Should this instead be called "ignore-dscp" or "skip-dscp”? > > We used the same name as we saw it in RFC 4301, though we do not have any > problem at all to change it as suggested > >> >> * Related: does the dscp-mapping leaf only have significance if bypass-dscp >> is false? If so, is there some "must ../bypass-dscp ..." syntax that would >> be applicable? > > Yes, that would completely applicable. In fact if you see the list > dscp-mapping above we would include this must > > must '../bypass-dscp = "false"'; > > Is this reasonable?. > > >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> [[ comments ]] >> >> [ appendix A ] >> >> * WRT the df-bit description. I think something should say that this >> MUST be ignored or has no meaning when the local/remote IP addresses >> are IPv6 addresses. > > Correct. Done. > >> >> [ appendix D ] >> >> * "2001:DB8" -> "2001:db8” everywhere > > Fixed. >> >> RFC 5952 section 4.3 says: lowercase for hex characters. > > Ah ok. >> >> [ appendix E ] >> >> * "2001:DB8" -> "2001:db8” everywhere > > Fixed. > >> >> RFC 5952 section 4.3 says: lowercase for hex characters. >> >> >> [[ questions ]] >> >> [ section 6.2 ] >> >> * Why is spd-mask a hex-string when spd-mark is a uint32? I would have >> expected them both to be uint32 or, at a minimum, both the same type. >> >> In appendix A they both appear to be uint32. > > You’re completely right. It is a typo in Section 6.2. Fixed. > >> >> >> [[ nits ]] >> >> [ section 1 ] >> >> * Saying that SDN allows "users to directly program..." seemed a little odd >> (vis. common definitions of "users"). Perhaps s/users/administrators/, or >> "network operators"? Alternatively "allows I2NSF Users", perhaps. > > Administrators is good term. We can use that. > >> >> [ section 6.2 ] >> >> * s/Notificsation/Notification/ > > Fixed. >> >> * s/conform/constitute/g? > > Fixed. >> >> [ appendix A ] >> >> * "NOT ESP encapsulation." -> "NO ESP encapsulation.", perhaps > > Fixed. >> >> [ appendix B ] >> >> * s/typedef pfs-group{/typedef pfs-group {/ > > Fixed. >> >> * s/the only defined right now/the only one defined right now/ > > Fixed. >> >> * In the description for pad/identity/ipv4-address: >> >> "Specifies the identity as a single four (4) octet." -> >> "Specifies the identity as a single four (4) octet IPv4 address.” > > Fixed. > > Thank so you much again. >> >> >> >> _______________________________________________ >> I2nsf mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/i2nsf >> <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] <mailto:[email protected]> > ------------------------------------------------------- ------------------------------------------------------- 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] -------------------------------------------------------
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
