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

From: Erik Kline via Datatracker <[email-masked]>
Date: Sun, 01 Nov 2020 23:35:27 -0800

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

 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.

  Separately, what about a setting to explicitly configure the DSCP mark on
  the outer header for all encap'd packets?

[ 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?

  Should this instead be called "ignore-dscp" or "skip-dscp"?

* 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?

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

[ appendix D ]

* "2001:DB8" -> "2001:db8" everywhere

  RFC 5952 section 4.3 says: lowercase for hex characters.

[ appendix E ]

* "2001:DB8" -> "2001:db8" everywhere

  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.

[[ 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.

[ section 6.2 ]

* s/Notificsation/Notification/

* s/conform/constitute/g?

[ appendix A ]

* "NOT ESP encapsulation." -> "NO ESP encapsulation.", perhaps

[ appendix B ]

* s/typedef pfs-group{/typedef pfs-group {/

* s/the only defined right now/the only one defined right now/

* 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."

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Tue, 3 Nov 2020 13:05:32 +0100

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-masked]> escribió:
> 

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). 

>  the outer header for all encap'd packets?

Yes, that is reasonable (see our comments below). 

>  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

>  is false?  If so, is there some "must ../bypass-dscp ..." syntax that would

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?.

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.

>  In appendix A they both appear to be uint32.

You’re completely right. It is a typo in Section 6.2. Fixed.

>  "network operators"?  Alternatively "allows I2NSF Users", perhaps.

Administrators is good term. We can use that.

> * s/Notificsation/Notification/

Fixed.
> * s/conform/constitute/g?

Fixed.
> * "NOT ESP encapsulation." -> "NO ESP encapsulation.", perhaps

Fixed.
> * s/typedef pfs-group{/typedef pfs-group {/

Fixed.
> * s/the only defined right now/the only one defined right now/

Fixed.
>  "Specifies the identity as a single four (4) octet IPv4 address.”

Fixed.

Thank so you much again. 
> 
> 
> 
> _______________________________________________
> 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]
-------------------------------------------------------