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

From: Rafa Marin-Lopez <[email-masked]>
Date: Tue, 1 Dec 2020 13:46:06 +0100

Dear Magnus:

> El 27 nov 2020, a las 9:56, Magnus Westerlund <[email-masked]> escribió:
> 
> Hi,
> 
> Please see below. 
> 
> On Wed, 2020-11-25 at 14:48 +0000, Magnus Westerlund wrote:
>> 
>> 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.
>>> 
>>>> ----------------------------------------------------------------------
>>>> 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:
>>> 
> 
> Sorry, I think I lead you astray due to no understanding the context here
> sufficiently.

[Authors] No worries.

> So as long as the option is to turn on "Normal Mode" for tunnel
> processing of the ECN bits or not then you can disregard the whole thing about
> RFC 8311. The applications that will use alternative behaviors for ECN will have
> to know that the consumer understand the semantics. So in this case as the IPSec
> tunnel only copies the bits back and forth no additional action is needed. 

[Authors] We have a comment about this and regarding RFC 6040. As we mentioned in our previous e-mail, the RFC 6040 states:

"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 an IPsec tunnel ALWAYS copy the ecn bits from the inner to the outer header (normal mode). We do not see any other alternative.

In consequence, after this discussion, our proposal would be just to remove the leaf ecn since, according to this text, there is a single option: copy.

Does it sound reasonable?

> 
> So please remove the whole second sentence and the RFC8311 reference.
> 
> In addition to the first part of the below description. It only mentions the
> encapsulation action. So my quesiton, is this configuration only for the
> encapsulating entity, or for a whole tunnel and applied to both ends? If it is
> the later, then I think you should take note of the need to process the outer
> ECN field and remark per RFC6040. 

[Authors] For the outer ECN, we do not have any alternative either: according to RFC 6040, the decapsulator applies the table in Figure 4. 

Best Regards.

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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 1 Dec 2020 13:56:47 +0000

Hi,

Please see inline. 

On Tue, 2020-12-01 at 13:46 +0100, Rafa Marin-Lopez wrote:
> Dear Magnus:
> 
> > El 27 nov 2020, a las 9:56, Magnus Westerlund <
> > [email-masked]> escribió:
> > 
> [Authors] We have a comment about this and regarding RFC 6040. As we mentioned
> in our previous e-mail, the RFC 6040 states:
> 
> Therefore an IPsec tunnel ALWAYS copy the ecn bits from the inner to the outer
> header (normal mode). We do not see any other alternative.
> 
> In consequence, after this discussion, our proposal would be just to remove
> the leaf ecn since, according to this text, there is a single option: copy.
> 

I might be missing something here but I don't think removing the leaf is the
correct option unless you plan to mandate ECN processing by both endpoints to be
always on. So I think there is a binary configuraiton option between enabling
the RFC6040 processing between inner and outer headers, and to not have ECN
enabled at all, i.e. set ECN bits to Not-ECN on the outer encapsulation. Copying
the bits on the ingress and not have the egress do the corresponding operation
have some negative consequences to fairness. 

Also, I cringe a bit when you says copy. Becasue that what 6040 + 4301 defines
in not strictly copying. That is why it is important to have the right
formulation and not call it copy. 

Cheers

Magnus

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Tue, 1 Dec 2020 16:44:31 +0100

Dear Magnus:

Please see our comments inline:

> El 1 dic 2020, a las 14:56, Magnus Westerlund <[email-masked]> escribió:
> 
> Hi,
> 
> Please see inline. 
> 
> always on.

[Authors] We think we may also be missing something. Your sentence “to mandate ECN processing by both endpoints to be always on.” is the key. It turns out that (under our interpretation of) RFC 6040 - section 4.3 mentions precisely that that you have ECN in both endpoints for IPsec tunnels: 

"Therefore, both endpoints of an RFC 4301
 tunnel can be sure that the other end is compatible with 
RFC 4301, because the tunnel is only formed after IKEv2 key
management has completed, at which point both ends will be
compliant with RFC 4301 by definition.  Therefore an IPsec tunnel
ingress does not need compatibility mode, as it will never
interact with legacy ECN tunnels.  To comply with the present
specification, it only needs to implement the required normal
mode, which is identical to the pre-existing RFC 4301 behaviour.

Moreover, related with this,  Section 2.24 Explicit Congestion Notification (ECN) in RFC 7296 mentions

2.24.  Explicit Congestion Notification (ECN)

When IPsec tunnels behave as originally specified in [IPSECARCH-OLD],
   ECN usage is not appropriate for the outer IP headers because tunnel
   decapsulation processing discards ECN congestion indications to the
   detriment of the network.  ECN support for IPsec tunnels for
   IKEv1-based IPsec requires multiple operating modes and negotiation
   (see [ECN]).  IKEv2 simplifies this situation by requiring that ECN
   be usable in the outer IP headers of all tunnel mode Child SAs
   created by IKEv2.  Specifically, tunnel encapsulators and
   decapsulators for all tunnel mode SAs created by IKEv2 MUST support
   the ECN full-functionality option for tunnels specified in [ECN] and
   MUST implement the tunnel encapsulation and decapsulation processing
   specified in [IPSECARCH] to prevent discarding of ECN congestion
   indications.

[Authors] Therefore , it seems from both texts above, that it is assumed that ECN would be always on for the IPsec tunnels. Are we missing something here?

> So I think there is a binary configuraiton option between enabling

[Authors] Our doubt is that, according to the text pasted above, what would be the case where we have to set ECN bits to Not-ECN if the assumption from these two RFCs is that both endpoints are ECN capable? Are we missing something regarding to IPsec tunnels according to RFC 6040?

In the IKE less case, the I2NSF Controller can assume (and know) that these NSFs have ECN full-functionality as happens with IKEv2. In any case, if you foresee a case where one of the endpoints is not ECN, adding the leaf ecn is not major problem at all. 

What do you think?

> formulation and not call it copy. 

[Authors] We understand. Does “setting” sound better?

Many thanks.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 1 Dec 2020 17:28:39 +0000

Hi,

See inline. 

On Tue, 2020-12-01 at 16:44 +0100, Rafa Marin-Lopez wrote:
> > El 1 dic 2020, a las 14:56, Magnus Westerlund <
> > > > RFC 8311. The applications that will use alternative behaviors for ECN
> > > > will
> > > > have
> > > > to know that the consumer understand the semantics. So in this case as
> > > > the
> > > > IPSec
> [Authors] We think we may also be missing something. Your sentence “to mandate
> ECN processing by both endpoints to be always on.” is the key. It turns out
> that (under our interpretation of) RFC 6040 - section 4.3 mentions precisely
> that that you have ECN in both endpoints for IPsec tunnels: 
> 
> [Authors] Therefore , it seems from both texts above, that it is assumed that
> ECN would be always on for the IPsec tunnels. Are we missing something here?

It is great that support is mandated. I think I am making a difference between
supporting and using. But it looks like this would work without any
configuration, thus you might be correct that this is not a necessary and it can
be removed. 

> [Authors] Our doubt is that, according to the text pasted above, what would be
> the case where we have to set ECN bits to Not-ECN if the assumption from these
> two RFCs is that both endpoints are ECN capable? Are we missing something
> regarding to IPsec tunnels according to RFC 6040?
> 
> In the IKE less case, the I2NSF Controller can assume (and know) that these
> NSFs have ECN full-functionality as happens with IKEv2. In any case, if you
> foresee a case where one of the endpoints is not ECN, adding the leaf ecn is
> not major problem at all. 
> 
> What do you think?

I think that requires domain knowledge of the IPSec endpoints to know if they
usually are fully compliant or if this needs configuration anyway. I don't know
this. So this I think is a consideration if one can remove the leaf or nto.

> [Authors] We understand. Does “setting” sound better?

"Setting it per RFC 6040" is more to my liking. 

Cheers

Magnus

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Mon, 14 Dec 2020 17:41:01 +0100

Dear Magnus:

Just to check we came to a conclusion to this discussion. Please see below.

> El 1 dic 2020, a las 18:28, Magnus Westerlund <magnus.westerlund=[email-masked]> escribió:
> 
> Hi,
> 
> See inline. 
> 

[Authors] Ok, good. So let’s remove it, then.
> this. So this I think is a consideration if one can remove the leaf or nto.

[Authors] Our point was to highlight that both endpoints have ECN full-funcionality as per section 4.3 in RFC 6040. In fact, we only consider that NSFs are complaint with RFC 4301. In conclusion, it is safe to remove the leaf. Therefore, there is no choice for the I2NSF Controller to configure ECN support since the NSFs are assumed to be ECN full-functional. After this discussion, we believe it is important to mention this in the I-D in section 6 as follows:

"It is assumed that NSFs involved in this document provide ECN full-functionality to prevent discarding of ECN congestion indications." 

We believe this clarifies the point. What do you think?

> "Setting it per RFC 6040" is more to my liking. 

[Authors] Noted.

Thank you very much.
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/i2nsf <https://www.ietf.org/mailman/listinfo/i2nsf>
------------------------------------------------------- Rafa Marin-Lopez, PhD

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 Dec 2020 08:28:03 +0000

Hi,

Yes, I think the proposed way forward is appropriat and that this has been
concluded. I will clear when an updated document is available.

Cheers

Magnus

On Mon, 2020-12-14 at 17:41 +0100, Rafa Marin-Lopez wrote:
> > El 1 dic 2020, a las 18:28, Magnus Westerlund <
> > magnus.westerlund=[email-masked]> escribió:
> > 
> > Hi,
> > 
> > See inline. 
> > 
> > > > > > processing of the ECN bits or not then you can disregard the whole
> > > > > > thing
> > > > > > about
> > > > > Therefore an IPsec tunnel ALWAYS copy the ecn bits from the inner to
> > > > > the
> > > > > outer
> > > > correct option unless you plan to mandate ECN processing by both
> > > > endpoints
> > > > to be
> > > > always on.
> > > 
> > > Moreover, related with this,  Section 2.24 Explicit Congestion
> > > Notification
> > > (ECN) in RFC 7296 mentions
> > > 

Yes

> [Authors] Our point was to highlight that both endpoints have ECN full-
> funcionality as per section 4.3 in RFC 6040. In fact, we only consider that
> NSFs are complaint with RFC 4301. In conclusion, it is safe to remove the
> leaf. Therefore, there is no choice for the I2NSF Controller to configure ECN
> support since the NSFs are assumed to be ECN full-functional. After this
> discussion, we believe it is important to mention this in the I-D in section 6
> as follows:
> 
> "It is assumed that NSFs involved in this document provide ECN full-
> functionality to prevent discarding of ECN congestion indications." 
> 

Yes, I am fine with that.