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

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

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=[e-mail]> escribió:
> 
> Hi,
> 
> See inline. 
> 
> On Tue, 2020-12-01 at 16:44 +0100, Rafa Marin-Lopez wrote:
>> Dear Magnus:
>> 
>> Please see our comments inline:
>> 
>>> El 1 dic 2020, a las 14:56, Magnus Westerlund <
>>> [e-mail]> escribió:
>>> 
>>> 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 <
>>>>> [e-mail]> escribió:
>>>>> 
>>>>> 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?
>>> 
>>> 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.
>> 
>> [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?
> 
> 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] Ok, good. So let’s remove it, then.
>  
> 
> 
> 
>> 
>>> 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. 
>> 
>> [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] 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?

> 
> 
>> 
>>> 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. 
>> 
>> [Authors] We understand. Does “setting” sound better?
> 
> "Setting it per RFC 6040" is more to my liking. 

[Authors] Noted.

Thank you very much.
> 
> Cheers
> 
> Magnus
> _______________________________________________
> 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]
-------------------------------------------------------