[I2nsf] Fwd: Erik Kline's Discuss on draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: (with DISCUSS and COMMENT)

[Rafa Marin-Lopez <[e-mail]>]

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 <[e-mail]>
> 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 <[e-mail]>
> Cc: Rafa Marin-Lopez <[e-mail]>, The IESG <[e-mail]>, [e-mail], [e-mail], Yoav Nir <[e-mail]>, [e-mail]
> 
> 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 <[e-mail] <mailto:[e-mail]>> 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
>> [e-mail] <mailto:[e-mail]>
>> 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: [phone] Fax: [phone] e-mail: [e-mail] <mailto:[e-mail]>
> -------------------------------------------------------

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