> On Oct 30, 2022, at 6:33 PM, Daniel Migault <mglt.i...@gmail.com> wrote:
>
> 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.
We need to get terms clarified. The IPsec tunnel Ingres encapsulates source
fragments. The IPsec tunnel egress defragments.
> 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.
The ingress does source fragmentation as needed. The egress might know which
fragments got through, but that assumes a PLPMTU discovery mechanism (where the
source tries different fragment sizes), which isn’t what you’ve described. But
either way, this tells you the size of the packets that get through the tunnel.
Note: there are two different sizes that are relevant here: the path MTU of the
tunnel (the source has to fragment packets into chunks no larger than that or
they won’t traverse the tunnel) and the egress reassembly size (EMTU_R of the
egress). The only packet the egress can’t reassemble is one that exceeds EMTU_R.
However, the doc talks about the MTU downstream of the egress, which is (best
case) the path MTU from the egress to the destination or (worst case) just the
link MTU of the next hop out of the egress. Nothing the ingress does has any
bearing on packets that traverse that path - once they leave the egress,
they’re just the origin packets.
> 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.
How? It can’t send an ICMP because it doesn’t have *the* packet causing the
problem to “reflect” back to the source. The ingress may not know who the
source is (there may be thousands or millions of sources). So which source?
I still don’t see a useful mechanism here - I recommend you take a look further
at the tunnels draft (which explains all of this in detail.
> I do believe that the communication between the ingress and egress security
> gateway is in scope of IPsec.
It definitely is, but the questions here are many:
- what information do you think the egress has that is useful to share
with the ingress?
- what would the ingress do what that information if thad it?
> My perception is that it is an ICMP PTB with the assurance the message is
> received.
ICMP PTBs can (and do, in some cases) happen on the tunnel and go back to the
tunnel ingress.
> 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.
First, it won’t work when they’re not the same node. Second, it won’t work
unless you know which source on that node to signal - which you don’t.
> Then, do you have any recommendations to achieve what we are trying to
> achieve ?
Again, please read the tunnels draft; it explains why this isn’t useful.
Joe
>
> Yours,
> Daniel
—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com
>
>
>
>
>
>
>
>
> On Sun, Oct 30, 2022 at 6:04 PM to...@strayalpha.com
> <mailto:to...@strayalpha.com> <to...@strayalpha.com
> <mailto:to...@strayalpha.com>> 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 <http://www.strayalpha.com/>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org <mailto:IPsec@ietf.org>
>> https://www.ietf.org/mailman/listinfo/ipsec
>
>
> --
> Daniel Migault
> Ericsson
> _______________________________________________
> 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
