Dear Magnus: Please see our comments inline:
> El 1 dic 2020, a las 14:56, Magnus Westerlund > <[email protected]> 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 < >>> [email protected]> 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? > 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? > 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? Many thanks. > > > Cheers > > Magnus ------------------------------------------------------- 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
