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
> >
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
