On 10/15/20 5:20 PM, Christian Hopps wrote:
I do not think there is IP protocol number for IPv5, but if you really
want to have protocol number, why not use 253 that is reserved for
experimientation and testing.
There is it's officially called "Internet Stream Protocol". Lou could speak
more a
> On Oct 15, 2020, at 4:48 PM, Tero Kivinen wrote:
>
> Christian Hopps writes:
>> We are defining the payload in this document, the payload is meant
>> for ESP. ESP has a payload identifier why can't we use it?
>
> If that is only possible value the next-header field can have as all
> packets
Christian Hopps writes:
> We are defining the payload in this document, the payload is meant
> for ESP. ESP has a payload identifier why can't we use it?
If that is only possible value the next-header field can have as all
packets of the Child SA which has been negotiated with USE_IPTFS then
what
Christian Hopps writes:
> > Earlier there was also another encapsuluation mode called a Bound
> > End-to-End Tunnel (BEET) mode for ESP [1] that was also proposed, and
> > in that case it would have been impossible to detect the mode from the
> > incoming packet, as lots of the information needed t
Hi Tero,
We are defining the payload in this document, the payload is meant for ESP. ESP
has a payload identifier why can't we use it? It feels like the clean KISS
solution to me. Yes, we are doing IKE negotiation, but using the designed for
payload identifier also allows the payload to be iden
Hi Paul,
My comment was only about using the next header field in ESP to identify the
ESP payload. I believe we've already agreed to remove the zero-conf section as
too controversial.
Tero, is suggesting that we should not use the next header field at all. That
is what I don't understand.
Tha
Christian Hopps writes:
> 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
On Wed, 14 Oct 2020, 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
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
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 fro
Hi Lou,
Valery,
>If IKE is used to negotiate using IP-TFS, then such switching MUST NOT
> take place.
I read this added line as saying you can switch from tunnel to TFS, I think you
mean that use of TFS is controlled via IKE. How about?
If IKE is used to negotiate using IP-TFS, then
Tero,
are you saying you not happy with the proposed text as discussed
with valery?
Thanks,
Lou
On 10/13/2020 5:00 PM, Tero Kivinen wrote:
Lou Berger writes:
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
Lou Berger writes:
> > 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 o
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-T
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 firs
Valery,
> If IKE is used to negotiate using IP-TFS, then such switching MUST
NOT take place.
I read this added line as saying you can switch from tunnel to TFS, I
think you mean that use of TFS is controlled via IKE. How about?
If IKE is used to negotiate using IP-TFS, then use of TF
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-sid
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-si
> I can live with MAY.
OK, but it must be negotiable in any case if you plan to use it with IKE.
Otherwise we'll get black holes.
> On 10/13/2020 9:16 AM, Valery Smyslov wrote:
> > If you badly need this feature, then please make it MAY and negotiable,
> > so that people can ignore it. SHOULD is
I can live with MAY.
On 10/13/2020 9:16 AM, Valery Smyslov wrote:
If you badly need this feature, then please make it MAY and negotiable,
so that people can ignore it. SHOULD is too strong for it,
leaving it non-negotiable is just unacceptable, IMHO.
___
Hi Chris,
IPTFS is not always negotiated, as IKE is not always used. Supporting zero-conf
IPTFS receive is very useful for supporting these
non-IKE use-cases.
If you plan to use IPTFS without IKE, then make it clear in the draft
that
Zero-Conf is only applicable for
> On Oct 13, 2020, at 9:16 AM, Valery Smyslov wrote:
>
> Hi Lou,
>
>> Valery,
>>
>> Please see below.
>>
>> On 10/13/2020 3:22 AM, Valery Smyslov wrote:
>>> Hi Chris,
>>>
Hi ipsecme and chairs,
This is a small update to the IPTFS draft which incorporates the last 2
cha
Hi Lou,
> Valery,
>
> Please see below.
>
> On 10/13/2020 3:22 AM, Valery Smyslov wrote:
> > Hi Chris,
> >
> >> Hi ipsecme and chairs,
> >>
> >> This is a small update to the IPTFS draft which incorporates the last 2
> >> changes that had been requested
> over
> >> the last year or so.
> >>
> >
> On Oct 13, 2020, at 7:27 AM, Lou Berger wrote:
>
> Valery,
>
> Please see below.
>
> On 10/13/2020 3:22 AM, Valery Smyslov wrote:
>> Hi Chris,
>>
>>> Hi ipsecme and chairs,
>>>
>>> This is a small update to the IPTFS draft which incorporates the last 2
>>> changes that had been requested
Valery,
Please see below.
On 10/13/2020 3:22 AM, Valery Smyslov wrote:
Hi Chris,
Hi ipsecme and chairs,
This is a small update to the IPTFS draft which incorporates the last 2 changes
that had been requested over
the last year or so.
1. As requested last year, it dispenses with the late-en
Hi Chris,
> Hi ipsecme and chairs,
>
> This is a small update to the IPTFS draft which incorporates the last 2
> changes that had been requested over
> the last year or so.
>
> 1. As requested last year, it dispenses with the late-enabled functionality,
> replacing it with a SHOULD clause
> su
Hi ipsecme and chairs,
This is a small update to the IPTFS draft which incorporates the last 2 changes
that had been requested over the last year or so.
1. As requested last year, it dispenses with the late-enabled functionality,
replacing it with a SHOULD clause supporting receiving IPTFS enca
35 matches
Mail list logo
