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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
