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 < > > [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? 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. > > > 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. > > > 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. Cheers Magnus
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
