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
