What is intended is that an implementation can process inbound IPTFS payloads w/o actually explicitly configuring the inbound SA to be in "IPTFS-mode" (zero-conf). That is all.
Thanks,
Chris.
> On Oct 14, 2020, at 4:01 AM, Valery Smyslov <smyslov.i...@gmail.com> wrote:
>
> HI Chris,
>
>> 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.
>
> I admit, that English is not my native language :-), but the text in the
> draft in my reading
> suggests exactly what you write it is not suggesting - switching to IP-TFS in
> the middle of tunnel operation
> ("on receipt of the first IP-TFS payload"):
>
> 2.4. Zero-Conf Receive-Side Operation On The SA.
>
> 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.
>
> If you intention was to require that all implementations SHOULD just support
> receiving IP-TFS packets
> (say, should implement IP-TFS), then the requirement is strange for me -
> in fact you require that all implementations support this extension.
>
> So, if you really meant some other thing, then the current text
> must be completely rewritten, so that it is clear for non-native readers
> (like me).
>
> Regards,
> Valery.
>
>> 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 <smyslov.i...@gmail.com> 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).
>>>> --
>>>> kivi...@iki.fi
>>>
>
>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
