Christian Hopps wrote:
> I really don't understand the extreme back pressure against using ESP
> the way it was designed. The next-header field is supposed to identify
> the payload, it does so for every other payload ESP carries. Any other
> solution to somehow infer the payload
Thanks Valery. Based on the subsequent discussions, I suspect it may be
best to just drop the whole section/capability. So much for postel's law...
Lou
On 10/14/2020 2:26 AM, Valery Smyslov wrote:
Hi Lou,
Valery,
> If IKE is used to negotiate using IP-TFS, then such switching
MUST NOT
> On Oct 14, 2020, at 6:19 AM, Tero Kivinen wrote:
>
> Christian Hopps writes:
>> 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.
>
> And if IKE is used what i
I really don't understand the extreme back pressure against using ESP the way
it was designed. The next-header field is supposed to identify the payload, it
does so for every other payload ESP carries. Any other solution to somehow
infer the payload type some other way *has* to be seen as a hack
Christian Hopps writes:
> 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.
And if IKE is used what is the use case for that?
IKE allows easy way of agreeing on the
Valery Smyslov writes:
> 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
> >
> >
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 wrote:
>
> HI Chris,
>
>> Indeed, this isn't about swi
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
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 wha
