Hi
I would like to share the following draft that has previously been
presented in the ipsecme working group, and we are currently seeking
feedback from a TRANSPORT perspective.
https://datatracker.ietf.org/doc/draft-liu-ipsecme-ikev2-mtu-dect/
We are scheduled to be on the agenda of tsvwg, and thought any feed back
is appreciated, I have specific inquiries for the working group:
1. Are there any potential adverse effects related to transmitting MTU
information of the data channel (IPsec/ESP) through the control channel
(IKEv2)?
2. Are there existing mechanisms that should be considered instead,
which can be feasibly implemented for our use case?
Transport description of the document:
Reassembly operations impose significant costs on the ingress security
gateway. When IP packets traverse an IPv4 network with DF=0, mid-tunnel
fragmentation occurs (and it is not possible to set DF to 1, as noted in
section 1.3). To mitigate this issue, the draft outlines a method for
the egress security gateway to inform its ingress counterpart that
reassembly operations are in progress. Specifically, when the ingress
security gateway receives a fragmented IPsec/ESP packet on the data
channel, it notifies the egress security gateway with a message that
includes the IP version of the packet and the length of the fragment.
This notification is sent via the IPsec control channel (i.e., IKEv2),
ensuring that it is both __received__ and authenticated.
Upon receiving this notification, the ingress security gateway
propagates the MTU information to prevent fragmentation - which is a
common practice in IPsec (as detailed in RFC4301 Section 8).
Additionally, the draft discusses a further notification mechanism where
LMTU and EMTU_R information can be conveyed, either as supplementary
data or when the received IPsec/ESP exceeds the LMTU or when the
reassembled packet surpasses the EMTU_R.
Yours,
Daniel
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
