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: ipsec@ietf.org; Paul Wouters <paul.wouters=40aiven...@dmarc.ietf.org>
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 <ipsec-boun...@ietf.org> On Behalf Of Harold Liu
Sent: Thursday, February 24, 2022 11:21 AM
To: ipsec@ietf.org; Paul Wouters <paul.wouters=40aiven...@dmarc.ietf.org>
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=40aiven...@dmarc.ietf.org>
Sent: Thursday, February 24, 2022 6:38 AM
To: Harold Liu <harold....@ericsson.com>
Cc: ipsec@ietf.org
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
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
