Re: [IPsec] New Version Notification for draft-liu-ipsecme-ikev2-mtu-dect-00.txt

[Harold Liu <[e-mail]>]

Paul, I think your following concern is meaningful by further consideration. After all, a larger MTU can increase transmission efficiency. I think it would be appropriate to add the following mechanisms to provide the ability to increase MTU, please kindly share your opinion.

- As paths over the internet change, this draft can kick in to reduce
   the size, but I see no method to go back to a larger size once the
   path between the endpoints recovers again.

<Harold>
       1 - After receiving the "ALLOWED_MTU" notify message, the sender device will do some special processing - ICMP or pre-fragmentation - as described in this draft if  the sender finds the MTU of original packet after ESP encapsulation exceeds the "ALLOWED_MTU".
       2- The specific actions on sender device after receiving "ALLOWED_MTU" should have a "time limit". When the "time limit" is exceeded, no special processing - like MTU check before ESP encapsulation - is performed on the original packet and the normal process is returned.
       3 - This "time limit" ensures that the session reverts to its original state - process original packets normally - after a certain amount of time - equivalent to a redetection of the path MTU so that MTU changes can be handled. If the ESP packet's size exceeds path MTU again the ESP receiver device could detect new MTU and send " ALLOWED_MTU ".
       4 - The recommendation at the implementation level is that this "time limit" should be flexible, in other words configurable.  Because in theory, the path MTU does not change frequently, and redetection of the MTU may temporarily introduce packet loss (Or other problems) caused by ESP fragmented packets. Therefore, users should decide the "time limit" value based on actual network conditions.
</Harold>

Paul, thank you very much for all of your suggestions, which are really of great help to improve the completeness and usability of this draft.

Brs

-----Original Message-----
From: Harold Liu 
Sent: Thursday, February 24, 2022 3:51 PM
To: [e-mail]; Paul Wouters <paul.wouters=[e-mail]>
Subject: RE: [IPsec] New Version Notification for draft-liu-ipsecme-ikev2-mtu-dect-00.txt

Paul, I further consider your concern below and I think I did not deep understand it before.
You are right currently there is no mechanism to recover to a larger MTU, I will further think of it and update to you later.
Again, really thank you for your valuable comments.

- As paths over the internet change, this draft can kick in to reduce
   the size, but I see no method to go back to a larger size once the
   path between the endpoints recovers again.

Brs

-----Original Message-----
From: IPsec <[e-mail]> On Behalf Of Harold Liu
Sent: Thursday, February 24, 2022 11:21 AM
To: [e-mail]; Paul Wouters <paul.wouters=[e-mail]>
Subject: Re: [IPsec] New Version Notification for draft-liu-ipsecme-ikev2-mtu-dect-00.txt

Paul, thanks for your comments and I am really glad that you are interested in this topic.

Please see my response inline.

-----Original Message-----
From: Paul Wouters <paul.wouters=[e-mail]>
Sent: Thursday, February 24, 2022 6:38 AM
To: Harold Liu <[e-mail]>
Cc: [e-mail]
Subject: Re: [IPsec] New Version Notification for draft-liu-ipsecme-ikev2-mtu-dect-00.txt

On Wed, 23 Feb 2022, Harold Liu wrote:

> Recently we ran into a real problem in some IPsec use case - In customer application scenarios, ESP packets are fragmented, which causes many problems - Including performance problems, device resource problems, and even traffic loss (In customer use case, it is IPsec over NAT scenarios so ESP packets are encapsulated by UDP.  Therefore, except for the initial fragment that contains complete UDP header, other fragments can only indicate UDP protocol in the IP address, but do not have UDP header. Therefore, they may be incorrectly identified by other applications and captured - The fragmented IP payload is regarded as a UDP header.  ESP cannot be reassembled and the package is lost).

When this happens, the application should be missing its packets, eg TCP or UDP and could reduce its MTU based on that as well. In other words, why would we want a second mechanism to do this, where these two mechanisms could end up fighting.
<Harold>
       The application cannot reduce its MTU when this happens because the packet lost, the application does not know the packet loss reason so as to cannot reduce the MTU and even cannot know what is appropriate to reduce to.
       For the TCP the standard action is retransmission according to sequence number received last time, but this could make trouble including but not limited to (I believe there are lots of description about TCP packets retransmission  disadvantages) performance is significantly affected from an application level, and this continues to happen because the MTU of retransmitted TCP does not change.
       UDP is an unsolid transmission mechanism, UDP itself does not have any mechanism to detect packet loss. Some application/protocols over UDP (eg NTP/SNMP/IKEv2) may check whether the expected packet is received and take corresponding actions - such as request retransmission or timeout detection - but cannot detect that the packet loss is caused by the MTU, and therefore cannot reduce the MTU.
       So there is no conflict between the two mechanisms.
</Harold>

> The below announcement is that draft. We would like to work with the community to improve and clarify tech draft.

Some concerns:

- What if a malicious entity able to filter on path would "fragment" the
   packet into tiny bits. It would reduce the MTU of the IPsec link to
   unhealthy size. There should be a minimum defined <Harold>
       You are absolutely right that malicious attacks are really an issue
       that must be considered and we should have a reasonable
       minimum MTU to filter such cases; I will update this to the draft.
</Harold>

- As paths over the internet change, this draft can kick in to reduce
   the size, but I see no method to go back to a larger size once the
   path between the endpoints recovers again.
<Harold>
       What you mentioned is a problem indeed.
       In fact, this is an oversight I made when writing the draft.
       The scheme itself can cover scenarios in which the MTU
       changes - mainly increases in size - this mechanism should
       continuously checks whether the incoming ESP packets are
       fragmented, if the incoming ESP packets are fragmented
       calculate the MTU and notify the peer end again.
       I will describe this explicitly in the next draft update.
</Harold>

- How does this interact with ESP padding ?
<Harold>
       I don't see any obvious problems working with ESP padding
       especially combined with your first concern - minimum-limiting
       MTU to prevent attacks, the ESP padding is less risky;
       Perhaps I should have added some description in section 5,
       stating that ESP tailer (Include padding) should be considered
       in addition to tunnel header length and ESP header length
       when calculating MTU;
</Harold>

- I can see applications just sending a 1200 MTU request "just to make
   it always work", which basically means a few years down the line,
   everyone ends up with reduced MTU. This is what happened with IPsec/L2TP
   where the ppp interface is basically 1200 everywhere.
<Harold>
       IMHO, PPP/L2TP is a bit outdated. At present 4G/5G IP RAN networks are
       basically over Ethernet, with typical topologies as follows:
       UE <-> Radio <-> (Baseband, optional) <-> FrontHaul <-> BackHual <-> Internet <-> Core
       The "Internet" is what we cannot fully control offten, so ESP MTU issues happen from time to time.
</Harold>

Paul

_______________________________________________
IPsec mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ipsec