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

[Christian Hopps <[e-mail]>]

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 <[e-mail]> 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).
>> --
>> [e-mail]
>