Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

[to...@strayalpha.com]

Hi, Daniel,

> On Jan 16, 2023, at 6:37 AM, Daniel Migault  wrote:
> ...
> On Sat, Jan 14, 2023 at 1:01 AM to...@strayalpha.com 
>   > wrote:
>> ...
>> However, that’s the issue. The reasons why what you’re trying to do isn’t 
>> useful is already covered in detail in intarea-tunnels - and why not to do 
>> it using IPv4 DF=0 in rfc6864. 
>> 
> rfc6864 provides requirements of IP ID. DF=1 for inner and outer packet 
> prevents using IP ID, but as mentioned DF=1 for outer is not possible in our 
> case

I’ve already explained how it is.

> and I am not sure we can enforce DF=1 in the inner packet as well. 

You don’t need to.

> Our proposal results in limiting fragmentation as well - when possible - and 
> as such makes these requirements easier to meet.

Any new use of DF=0 is directly against rfc6864 recommendations 
Additionally, you’re creating a new mechanism that is relevant only for IPv4; 
IPv6 has no DF=0 equivalent. That’s against current general advise not to focus 
on new IPv4-only approaches.

>> It’s not useful to have an email exchange rehashing that content message by 
>> message.
>> 
> The conversation has been clarifying to us - at least regarding the 
> terminology and we believe the document has improved, so that has been 
> somewhat useful and we thank you for these feedbacks.
> While DF=1 is the recommended way, it is not an option for us - unless proven 
> otherwise.

DF=0 requires you to enforce that you don’t reuse IDs during potential 
reassembly overlap, which requires knowing that AND setting the appropriate 
reassembly timeout at the receiver. You don’t do that so you don’t have a 
solution, IMO.

And DF=0 works only for IPv4, so that’s another reason you don’t have a 
solution. Any solution for IP should work for IPv6 first; if it also works (or 
doesn’t) for IPv4, that ought to be secondary at this point.

> **With DF=0**, we do measure some significant performance improvement by 
> using our proposal and so far, I have been able to see any reasons for not 
> doing it.

Improved performance only because you don’t check or enforce ID uniqueness. 

> If such reasons exist, it would be clarifying to explicitly mention them 
> explicitly (to me and the WG) so these could be considered..  

I have been explicit about these problems before as well.

Joe___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

[Daniel Migault]

Hi,

Thanks for the feedback. Please see below my comments/responses.

Yours,
Daniel
On Sat, Jan 14, 2023 at 1:01 AM to...@strayalpha.com 
wrote:

> Daniel,
>
> On Jan 13, 2023, at 8:33 PM, Daniel Migault  wrote:
>
> f not, to better understand, do we have an example of a packet that cannot
> be processed if the MTU is set to tunMAP but that can be processed if the
> MTU is set to EMTU_R.
>
>
> As per intarea-tunnels, MTU is a highly overloaded term.
>
> Tunnels relay packets that exceed their tunMAP but not their tunMTU
> (EMTU_R - headers) using source fragmentation all the time.
>

correct, we need to remove encaps.

However, that’s the issue. The reasons why what you’re trying to do isn’t
> useful is already covered in detail in intarea-tunnels - and why not to do
> it using IPv4 DF=0 in rfc6864.
>
> rfc6864 provides requirements of IP ID. DF=1 for inner and outer packet
prevents using IP ID, but as mentioned DF=1 for outer is not possible in
our case and I am not sure we can enforce DF=1 in the inner packet as
well. Our proposal results in limiting fragmentation as well - when
possible - and as such makes these requirements easier to meet.

It’s not useful to have an email exchange rehashing that content message by
> message.
>
> The conversation has been clarifying to us - at least regarding the
terminology and we believe the document has improved, so that has been
somewhat useful and we thank you for these feedbacks.
While DF=1 is the recommended way, it is not an option for us - unless
proven otherwise. **With DF=0**, we do measure some significant performance
improvement by using our proposal and so far, I have been able to see any
reasons for not doing it. If such reasons exist, it would be clarifying to
explicitly mention them explicitly (to me and the WG) so these could be
considered..


Joe
>


-- 
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec