Tero,
are you saying you not happy with the proposed text as discussed
with valery?
Thanks,
Lou
On 10/13/2020 5:00 PM, Tero Kivinen wrote:
Lou Berger writes:
I have to admit that I have not read this draft, but noting, that most
of the cipher we use do require automated key management like IKE, I
just wonder are you really going to be limited to 3DES, or what
automated key management you are going to be using instead of IKE, and
how can you guarantee that it actually does its job correctly for
securing the key management over reboots etc.
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.
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).
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
