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

[Daniel Migault <[e-mail]>]

Thanks Joe for the feedback. I responded inline to your questions.

To the main question: what is this a solution for ? It is a solution to
avoid an ingress security gateway to become overloaded by de-fragmenting
packets. The main idea is that the ingress security gateway informs the
egress security gateway that fragmentation is occurring  with an indication
of the maximum size of the packet. In the best case scenario, the security
gateway informs the source node to reduce the size of the inner packet with
an ICP PTB packet for example.

I do believe that the communication between the ingress and egress security
gateway is in scope of IPsec. My perception is that it is an ICMP PTB with
the assurance the message is received. What I think you mean is outside the
scope of IPsec is sending an ICMP PTB message (in the case of a remote
node) or changing the MTU directly in the case the source node and security
gateway are the same entity. What is unclear to me is whether the current
design violates anything or why it wouldn't work.

Then, do you have any recommendations to achieve what we are trying to
achieve ?

Yours,
Daniel








On Sun, Oct 30, 2022 at 6:04 PM [e-mail] <[e-mail]>
wrote:

> There are some issues with the doc:
> - abstract has a typo, doc uses ’node’ where it should use ‘router’ for
> on-path frag, etc
>
easy to fix.

> - discussion should to be more specific with respect to RFCs 1122, 792,
> and 4821
>
Apart from 1122, we have all these references. If you still have in mind
what needs to be more specific that would help. From the text below, it
seems the use of egress / ingress should be used as opposed to upstream,
downstream. Is that what you mean ?

> - the overall problem is assumed but never clearly defined
>
> In the intro we have the following text that intends to capture that
we are willing to avoid reassembling.

  IPv4 packets are often fragmentable with
   their DF bit set to 0.  In this case, as described in [RFC0792], when
   a packet size exceeds its MTU, the node fragments the incoming packet
   in multiple fragments.  The inconvenient is that the receiving
   security gateway will have to re-assembled the multiple fragments to
   rebuilt an ESP packet before being able to apply the IPsec
   decapsulation.


I agree with Michael Richardson’s post of 8-16-22 on a few points:
> 1) it is premature for a TSV ART review of this document
> I’m not actually sure that TSV review is relevant, as tunneling is more an
> INTDIR issue (on which I do not sit),
> though I’m probably at least as appropriate a reviewer on tunnel issues
>
This is a chicken and egg issue. We do not want to design/discuss a
solution within the ipsecme WG without some feedback  that what we are
doing will not be opposed by the transport area.

> 2) this discussion is confusing as to both aspects and terminology of
> tunneling
> I encourage those interested review draft-intarea-tunnels - while expired
> (I’m getting back to it), it remains definitive in the IETF AFAICT
>
> The stated point of this work, rephrased, is to have the IPsec tunnel
> egress tell the IPsec tunnel ingress that the (next hop) link MTU out of
> the egress (i.e., after traffic exits the tunnel) is too small for the
> packets the egress node tries to forward.
>
Correct.

>
> So it tells the tunnel ingress that the egress link MTU is too small. But
> that MTU is of the origin packet (not the tunnel packet, which includes the
> source packet as a paylaad), which the tunnel ingress has no control over.
>
> My understanding is that you are saying the outer packet size is defined
by the inner packet size, so the reduction of the packet size needs to be
implemented by the source of the inner packet, and there is actually little
the IPsec egress tunnel security gateway can do.
If that is correct, I do agree that that information should be relayed to
the source node of the inner packet, but I believe this is what
we mentioned and section 4.2 lists 3 ways to handle this.
1) The IPsec egress tunnel security gateway can inform the source of the
inner packet to reduce its MTU with ICMP PTB. That inner MTU is derived
from the outer MTU.
2) The IPsec egress tunnel security gateway may perform the fragmentation
of the inner packet.
3) The IPsec egress tunnel security gateway may fragment itself the outer
packet.

I.e., this isn’t a signal from the egress to the ingress about the tunnel
> (path) MTU.
>
isn't it from ingress to egress ? Currently, in our proposal the IPsec
ingress security gateway is returning 2 type of information to the IPsec
egress security gateway:
* the fact that the outer IP packet is fragmented
* the value of the outer MTU.
As far as I understand, you seem to say this is not a signal related to the
inner communication (that is inside the tunnel). I tend to agree, but I
also do not see that information completely uncorrelated and we expect the
security gateway to "translate" that information to the source of the inner
packet. A huge advantage of such information is that it is being
transmitted by the ingress IPsec security gateway to the IPsec egress
security gateway over a secure channel. In our opinion this adds at least
some value over the ICMP PTB.In terms of information I tend to agree that
this information is similar except that that information can be assumed to
be received by the other security gateway.

Even if it were, then the tunnel ingress would be sending more fragments
> (at the tunnel ingress by source-fragmented at the outer header); it can’t
> change the MTU of the origin packets it happens to receive — that happens
> at the packet origin, which can be upstream of the ingress, or at a minimum
> is outside the scope of IPsec (even if the ingress and packet origin are a
> the same node).
>
> I do see two aspects. On that one security gateway provides some
information regarding its processing related to IPsec. At the very least
informing the egress security gateway that it straffic is causing a DDoS
seems in scope.
Now, it is also correct that providing such information if no action can be
taken is not very useful. In our case, we do mention some actions that can
be taken and one of these actions is that the security gateway sends an
ICMP PTB message. It is unclear to me if that is what you are mentioning as
out of scope of IPsec. I see this as similar to a router that needs to
fragment and sends to the source an ICMP PTB packet.


> What exactly is this a solution for?
>
The solution is to avoid the receiving gateway to re-fragment.

>
> Joe
> —
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com
>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>


-- 
Daniel Migault
Ericsson