Transforms aren't just about the encryption algorithm though (e.g., the
extended sequence number transform). In the IP-TFS case it's not about whether
one would enable TFS with a given encryption algorithm. Consider supporting
and/or selecting from the set of IP-TFS with congestion control, IP-T
Hi Chris,
> Transforms aren't just about the encryption algorithm though (e.g., the
> extended sequence number
> transform).
Whether you want to use ESN or not can depend on selected cryptographic
algorithms
(there is no point to use ESN unless algorithm allows to encrypt a large amount
of da
> On Nov 28, 2019, at 8:49 AM, Valery Smyslov wrote:
>
> 2. I don't think new IP protocol number is needed at all. Since SA is created
> with IKEv2,
> it is always known whether it is IPTFS SA or ordinary SA, so "Next
> Protocol"
> field in ESP trailer is redundant and can be filled
Hi Chris,
> > 2. I don't think new IP protocol number is needed at all. Since SA is
> > created with IKEv2,
> > it is always known whether it is IPTFS SA or ordinary SA, so "Next
> > Protocol"
> > field in ESP trailer is redundant and can be filled in with arbitrary
> > value (say zero)
> On Nov 29, 2019, at 7:09 AM, Valery Smyslov wrote:
>
> Hi Chris,
>
>> Transforms aren't just about the encryption algorithm though (e.g., the
>> extended sequence number
>> transform).
>
> Whether you want to use ESN or not can depend on selected cryptographic
> algorithms
> (there is n
> > It can easily be done with a single notification containing the proposed
> > features.
> > The responder would send back the notification indicating the features it
> > agrees to use.
> >
>
> I have some doubts about calling this "easy". This sounds a lot like the
> already existing transfo
> On Nov 29, 2019, at 8:13 AM, Valery Smyslov wrote:
>
> Hi Chris,
>
>>> 2. I don't think new IP protocol number is needed at all. Since SA is
>>> created with IKEv2,
>>>it is always known whether it is IPTFS SA or ordinary SA, so "Next
>>> Protocol"
>>>field in ESP trailer is redun
> > I envision a lively discussion with INT folks if we ask them for a "fake"
> > protocol number :-)
>
> I would not choose to refer to it as a fake protocol. The field is defined as
> an IPv4 or IPv6 protocol value to
> identify the ESP payload. IPsec/ESP is *the* standard for encrypting IP
>
> On Nov 29, 2019, at 11:14 AM, Valery Smyslov wrote:
>
>>> I envision a lively discussion with INT folks if we ask them for a "fake"
>>> protocol number :-)
>>
>> I would not choose to refer to it as a fake protocol. The field is defined
>> as an IPv4 or IPv6 protocol value to
>> identify
As I understand it, the question is:
ESP(np=??)[IP-fragment, .., IP-fragment, padding]
IPvX(np=ESP)
L2
What will the ?? be. I agree that it makes no sense to mark this as IPIP.
I see that we could re-use TF-ESP's number here if we got push-back.
a) It would make no sense to put a TF-ESP
Christian Hopps wrote:
> Additionally, I'm not sure that we should be so quick to say that the
> IP-TFS payload would never be used outside of ESP; as was pointed out
> by Michael using this payload does solve the PMTU issue with (IPsec)
> tunnels, it could be re-used for this pur
> On Nov 29, 2019, at 2:23 PM, Michael Richardson wrote:
>
>
> Christian Hopps wrote:
>> Additionally, I'm not sure that we should be so quick to say that the
>> IP-TFS payload would never be used outside of ESP; as was pointed out
>> by Michael using this payload does solve the PMTU issue w
On Nov 29, 2019, at 21:01, Valery Smyslov wrote:
> A lot of things in IKEv2 is negotiated by using notifications. With regard to
> child SA they are -
> using transport mode, using IPcomp, using WESP, using ROHC.
> IP-TFC looks to me like a natural continuation of this line.
I agree. This is
13 matches
Mail list logo
