Indeed, this isn't about switching a pair of SAs to IPTFS in the middle of the tunnel operation. This is only about supporting the receipt of IPTFS as a payload in ESP.
Zero conf (or globally config enabled) receive support of IPTFS payloads is seen by some as a real value add. I'm not sure what the kerfuffle is all about. :) Thanks, Chris. > On Oct 14, 2020, at 2:58 AM, Valery Smyslov <smyslov.i...@gmail.com> wrote: > > Hi Tero, > >>> I'm not advocating ike vs ike-less, just trying to have a comprehensive >>> solution. One example ikeless usecase is captured by the YANG model in >>> last call: >>> https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-09 >> >> Which will require similar behavior from the IPsec part than IKE, >> meaning you can't really change any parameters on the fly for existing >> SAs. You can't change for example the ciphers of the existing SA, and >> expect that to work. > > In fact, unlike changing e.g. cipher on the fly, that is not possible, > because the cipher used is not present in the ESP packet, so that you > cannot distinguish two ESP packets with different ciphers, you can distinguish > tunnel packets from IPTFS packets on receiving side > (by analyzing Next Header), so technically the proposed > switching is workable. That said, I fully agree with you > that it is a very bad idea and must be prohibited, > at least for traditional IPsec. > > I care less about other use cases (I recall that authors wanted > to use IPTFS not only for IPsec, but as more generic > mechanism to pack several IP packets into one). So, I may leave > with this option if it will be explicitly prohibited > for traditional IPsec. IKE-less (l2nsf) use case is a corner case, > I tend to agree with you that it should be prohibited > for this case too. > > Regards, > Valery. > >> My understanding for that is that ike-less will not change any >> parameters of the existing SAs in the SAD, as that would definitely >> break everything, but instead they will allocate new SPI, install new >> SAD entry, and then remove the old SAD entry which causes the traffic >> move to use the newly created SAD entry. >> >> So for that use, there is no point of having a way to turn on IPTFS in >> the middle of SA use time, exactly as there is no need to try to >> change algorithms of the existing SAs. If you do that kind of things, >> you just create new SA, and delete old one. I am not sure whether this >> should be reflected on the draft-ietf-i2nsf-sdn-ipsec-flow-protection >> somehow, i.e., indicating that most (if not all) of the items in the >> sad-entry are write once type of things, i.e., you can write them >> once, but you can't modify them once they have been set, and only way >> to change them is to delete the whole sad-entry and recreate it with >> new values (most likely doing it other way round, i.e., first create >> new and delete old). >> -- >> kivi...@iki.fi >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
