Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

[Lou Berger <[e-mail]>]

Hi Tero,

see below
On 10/13/2020 1:32 PM, Tero Kivinen wrote:
> Lou Berger writes:
>> Valery,
>>
>> How about this:
>>
>> OLD
>>     Receive-side operation of IP-TFS does not require any per-SA
>>     configuration on the receiver; as such, an IP-TFS implementation
>>     SHOULD support the option of switching to IP-TFS receive-side
>>     operation on receipt of the first IP-TFS payload.
>>
>> NEW
>>     Receive-side operation of IP-TFS does not require any per-SA
>>     configuration on the receiver; as such, for tunnels created
>>     without IKE, an IP-TFS implementation
>>     SHOULD support the option of switching to IP-TFS receive-side
>>     operation on receipt of the first IP-TFS payload for tunnels.
>>
>> I can live with MAY, but would prefer SHOULD.
>>
>> Does this work for you?
> 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

Lou