Valery Smyslov writes: > 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 have never understood why the IPTFS packets needs to be identified by the Next Header. We do not include cipher algorithm in the ESP packet, so that is known by the SA information. We could do exactly same for the IPTFS, i.e., if all packets inside the specific SA is always IPTFS packets, then there is no need to identify whether IPTFS is used or not in the Next Header field, and there would be no need to allocate new IP protocol number for this. If the reason we need new IP protocol number is just because they want to be able to this switching of the IPTFS on in the middle of the IPsec SA when NOT using IKE, then I think that is not very good reason for allocating new IP protocol number. > 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). I would like to understand what these other use cases are and how they affect the use case for IPsec. I mean if those use cases are just "we want to make generic mechanism" without any specific use cases, there is no need to think about the Early allocation of the IP protocol number. > So, I may leave with this option if it will be explicitly prohibited > for traditional IPsec. And if interoperability testing etc of the IPTFS in the IPsec use case is done using IKE, and in that case we do not need new IP protocol number, as we can know from the IPsec SA whether IPTFS is enabled or not. There is no need to know that per packet basis. And In that case IP protocol number allocation can be later, when other uses cases emerge. > IKE-less (l2nsf) use case is a corner case, I tend to agree with you > that it should be prohibited for this case too. Definitely. Actually I think the i2nfs document should probably say something about changing SAD stucture during on the fly. I would expect that most of the implementations in kernel do not really allow easy way of modifying the replay window or things like that while the SA is being used. In normal case there is no need to ever set the for example replay window, it will start from all zeros when SA is created, and automatically updated after that. Other things like sequence numbers or IV can cause serious security issues if they are modified wihtout following specific rules. With my quick check of the i2nfs draft I did not see whether it has any text saying those things are create once, and after that read only or not. I think it should have that kind of text somewhere.... -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
