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: > 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 < > > [email protected]> 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 < > > > > [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. > > [Authors] Ok, good. So let’s remove it, then. Yes > > > > > > > > > > > > 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? Yes, I am fine with that. > > > > > > > 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 > > [email protected] > > 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 protected] > ------------------------------------------------------- >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
