On Wed, Aug 2, 2023 at 10:29 PM Christian Hopps <cho...@chopps.org> wrote:
> > Daniel Migault <mglt.i...@gmail.com> writes: > > > On Tue, Aug 1, 2023 at 10:18 PM Christian Hopps <cho...@chopps.org> > > wrote: > > > > Hi, > > > > FWIW, Here's what I was saying at the mic during the ipsec > > meeting @117. It may have relevance to the discussion about > > EMTU... > > > > You own the tunnel endpoints since you're configuring security > > tunnels on them. Normal PMTU will work fine if, for some reason, > > you need your ingress to discover the egress endpoint's nexthop > > MTU (red-side link) dynamically. This is b/c your not going to > > configure your own tunnel endpoints to drop ICMP too big packets > > and break it yourself. So, you don't need any new mechanism to > > discover your own downstream red side link MTUs. > > > > > > I assume you mean PMTU between the ingress and egress node. We could > > use the normal PMTU mechanisms with ICMP but that is not always so > > easy and the information may not necessarily apply to IPsec traffic. > > Things that may make PMTU not that easy are router may not > > respond with ICMP PTB, ICMP PTB may be dropped by the network or > > firewall policies - one thing we need to consider is that the network > > between the two gateways is not managed by the same entity as the one > > operating the gateways. ). > > You're confusing inner and outer traffic here. When your egress endpoint > decaps the tunnel traffic, and then that traffic won't fit on it's egress > red link on your egress endpoint is going to send an ICMP too big message > back to the ingress router *inside the tunnel*. This has nothing to do with > the routers that carry the tunnel traffic. > Correct, I was talking about the outer traffic. For the inner I agree that PMTU should provide a MTU lower than EMTU_R (of the outer) and it should receive the ICMP PTB. > > > We were not expecting IKE PTB to take part of a PMTU process, but the > > IKE PTB is expected to be sent when the packet received is greater > > the EMTU_R (which is outside the scope of ICMP and a specific action > > performed by the egress security gateway) that is when fragmentation > > occurs - there are no mechanism that provide this data. It could be > > also used when an ESP packet is greater than the LMTU. In that latter > > case ICMP PTB and IKE PTB may play a similar role except that IKE PTB > > is authenticated and indicates the concerned SA. A typical ICMP PTB > > will not be able to indicate the SA for UDP encapsulated traffic. > > > > > > Also, I'm pretty sure that most transit routers are configured to > > never fragment forwarded packets (it's a DDOS attack vector), so > > I don't think your going to be seeing the outer ESP IP packet be > > fragmented either. This functionality is so unpopular it was > > completely eliminated from IPv6, so it for sure will never happen > > if your outer encap is IPv6. > > > > > > We do have mid tunnel fragmentation (with IPv4 of course). DF=0 is > > also preferred over dropping packets which results in a blackholing > > situation. > > Can I ask, who is providing this mid-tunnel fragmentation service for you? > Your upstream provider, or a DFZ transit network like AT&T? I'm curious b/c > it's surprising that anyone is providing this service anymore given it's an > attack vector on their network. :) > > Thanks, > Chris. > > > > > > Thanks, > > Chris. > > > > Daniel Migault <mglt.i...@gmail.com> writes: > > > > > Hi Ben, > > > > > > Just trying to position our understanding of the position > > between the ICMP PTB and the IKE PTB. > > > > > > If an incoming Encrypted packet is larger than the Link MTU, an > > ICMP PTB is sent, otherwise the packet is accepted. If fragments > > are received, a reassembly operation happens and the packet may > > be too large to be built or decrypted. I am unaware of any ICMP > > signaling between the gateway that could carry this information. > > As far as I understand, ICMP PTB is not issued for a reassembled > > packet as long as each of the fragments are below the MTU. This > > is the reason we send the EMTU_R which designates the maximum > > size the egress gateway can handle. > > > > > > EMTU_R could be a configuration parameter that would not > > change, but that value also considers the MTU of the router part > > which can be changed. > > > > > > As soon as it passes the interface, as I understand it, an ICMP > > PTB will be sent to the Source and not the gateway. As I > > understand it, EMTU_R defines the maximum payload the Link > > network is able to handle. In our case, the payload is the > > encrypted ESP packet that may have been reassembled. The packet > > is passed to the decryption. Once decrypted, the clear text > > packet is passed to the router of the node. The router may send > > an ICMP PTB, which will be sent to the Source or treat that > > packet. I see EMTU_R as reflecting the node of the router with > > Tunnel MTU = EMTU_R - ESP overhead > > > > > > Considering a ping encapsulated in esp - we may discover the > > MTU as well as the EMTU_R by fragmenting unless we meet EMTU_R. > > > > > > Note also that since we want to avoid fragmentation having a > > discovery mechanism that relies on fragmentation may not be the > > best idea. > > > > > > Yours, > > > Daniel > > > > > > > > > On Mon, Jul 31, 2023 at 1:22 PM Daniel Migault < > > mglt.i...@gmail.com> > > > wrote: > > > > > > An encapsulated ICMP ECHO would get a response from the > > router > > > (not the interface) of the security gateway. I have not > > read > > > carefully draft-colitti-ipsecme-esp-ping but this is > > potentially > > > what we could use to discover that path upon which we could > > set > > > DF=1. That said, if MTU changes, we need to receive a > > > notification. > > > I tend to think that extending colitti-ipsecme-esp-ping to > > other > > > ICMP plus defining PLMTU could replace our IKE PTB. > > > > > > > > > On Mon, Jul 31, 2023 at 12:57 PM Ben Schwartz < > > bem...@meta.com> > > > wrote: > > > > > > It seems to me that the statement "This packet is too > > big for > > > me to decrypt" is quite different from "This packet > > arrived > > > fragmented". The former can generally be negotiated in > > the > > > handshake, whereas the latter is a dynamic behavior of > > the > > > underlying path. > > > > > > Monitoring the Path MTU is important, even when the > > path > > > traverses an ICMP blackhole. So while I don't see the > > value > > > of the PTB extension, I can understand the rationale > > for the > > > LMAP extension. However, I would like to see a bit > > more > > > description of the whole system. How do I send path > > probes > > > to elicit these responses? Can I use ICMP ECHO inside > > the > > > tunnel, or do we need draft-colitti-ipsecme-esp-ping? > > If we > > > have path probes, why not just set DF=1 on the outer > > header > > > for PMTUD? > > > > > > --Ben Schwartz > > > > > > From: Daniel Migault <mglt.i...@gmail.com> > > > Sent: Monday, July 31, 2023 12:10 PM > > > To: Ben Schwartz <bem...@meta.com> > > > Cc: Harold Liu <harold.liu= > > 40ericsson....@dmarc.ietf.org>; > > > ipsec@ietf.org <ipsec@ietf.org> > > > Subject: Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB > > Notification > > > > > > Hi Ben, Please see my comments. On Mon, Jul 31, 2023 at > > > 10: 47 AM Ben Schwartz <bemasc@ meta. com> wrote: Hi > > Harold, > > > It sounds like you're describing a different problem. > > Daniel > > > mentioned a concern about cases in which "the encrypted > > > Hi Ben, > > > Please see my comments. > > > On Mon, Jul 31, 2023 at 10:47 AM Ben Schwartz < > > > bem...@meta.com> wrote: > > > > > > Hi Harold, > > > > > > It sounds like you're describing a different > > problem. > > > Daniel mentioned a concern about cases in which > > "the > > > encrypted packet is too big and so cannot be > > decrypted". > > > > > > We see the MTU indicating the size the packet > > the egress > > > interface is able to handle which includes the ability > > to > > > reassemble and decrypt the packet. In that sense, I see > > > sending the EMTU_R as very similar to an ICMP PTB > > except. I > > > am wondering if you see any reasons for these issues to > > be > > > considered differently and how you think such > > distinction > > > could help. > > > > > > That's quite different from an MTU limit on the > > > forwarding path, which can be dealt with using > > ordinary > > > IP fragmentation and PMTUD. > > > > > > Fragmentation works, but costs too much resources and > > this > > > draft is aiming at reducing such operations. Our > > concern is > > > with IPv4, where DF=1 leads to a blackholing situation. > > PMTUD > > > is extremely difficult as ICMP messages are not > > received by > > > the ingress gateway. > > > PLMTUD I-D.spiriyath-ipsecme-dynamic-ipsec-pmtu for ESP > > is > > > another path, but it would take a lot of effort. > > > > > > Yours, > > > Daniel > > > > > > > > > --Ben > > SchwartzI-D.spiriyath-ipsecme-dynamic-ipsec-pmtu > > > > > > From: Harold Liu <harold.liu= > > > 40ericsson....@dmarc.ietf.org> > > > Sent: Sunday, July 30, 2023 9:28 PM > > > To: Ben Schwartz <bem...@meta.com>; Daniel Migault > > < > > > mglt.i...@gmail.com> > > > Cc: ipsec@ietf.org <ipsec@ietf.org> > > > Subject: RE: [IPsec] -ikev2-mtu-dect: IKEv2 PTB > > > Notification > > > > > > Ben, thanks for your comment. Yes at the beginning > > we > > > thought what you thought, we consider the solution > > as > > > “Negotiate it up front (in IKEv2)”, however the > > challenge > > > here is the MTU of the router on the forwarding > > path can > > > be changed at any > > > > > > Ben, thanks for your comment. > > > > > > > > > > > > Yes at the beginning we thought what you thought, > > we > > > consider the solution as “Negotiate it up front (in > > > IKEv2)”, however the challenge here is the MTU of > > the > > > router on the forwarding path can be changed at any > > time > > > (for example, the router changes the configuration > > for > > > some reason, or changes the forwarding path for > > some > > > reason). > > > > > > > > > > > > If the MTU of any forwarding node on the forwarding > > path > > > changes (even as to the whole forwarding path > > changes), a > > > pre-negotiated MTU is probably not applicable. > > Therefore, > > > we defined the solution is to discover MTU in-band > > via > > > error responses. > > > > > > > > > > > > Brs > > > > > > > > > > > > From: IPsec <ipsec-boun...@ietf.org> On Behalf Of > > Ben > > > Schwartz > > > Sent: Saturday, July 29, 2023 8:01 AM > > > To: Daniel Migault <mglt.i...@gmail.com> > > > Cc: ipsec@ietf.org > > > Subject: Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB > > > Notification > > > > > > > > > > > > +mailing list (oops) > > > > > > > > > > > > I think I understand the difficulty here. In IPv6, > > a > > > "maximum reassembled ESP size" can be modeled as a > > > next-hop MTU on the plaintext, but in IPv4 an > > enormous > > > ESP could be decrypted and fragmented forward over > > a next > > > hop with a reasonable MTU. > > > > > > > > > > > > If this kind of ESP size limit is allowed, I think > > the > > > best architecture would be to negotiate it up front > > (in > > > IKEv2) since it is a static property of the > > endpoints, > > > rather than discovering it in-band via error > > responses. > > > > > > > > > > > > --Ben Schwartz > > > > > > > > > > > > From: Daniel Migault <mglt.i...@gmail.com> > > > Sent: Friday, July 28, 2023 10:47 AM > > > To: Ben Schwartz <bem...@meta.com> > > > Subject: Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB > > > Notification > > > > > > > > > > > > I see the next link as being the network behind the > > > egress security gateway in which case the paquet > > would be > > > the clear text packet. In that case maybe we could > > expect > > > a ICMP PTB being sent to the source. The scenario > > we have > > > is the packet > > > > > > I see the next link as being the network behind the > > > egress security gateway in which case the paquet > > would be > > > the clear text packet. In that case maybe we could > > expect > > > a ICMP PTB being sent to the source. > > > > > > The scenario we have is the packet being so big > > that > > > decryption cannot be performed - for example once > > > reassembled. The egress security gateway has an ESP > > > packet that it cannot process. The normal way > > would be to > > > send an ICMP PTB but that ICMP PTB does not contain > > > sufficient information for the egress to address > > the > > > issue. The IKE message could be seen as duplicating > > the > > > ICMP PTB with additional guarantees. > > > > > > > > > > > > Yours, > > > Daniel > > > > > > > > > > > > On Fri, Jul 28, 2023 at 1:33 AM Ben Schwartz < > > > bem...@meta.com> wrote: > > > > > > I don't understand what it would mean for an > > ESP > > > packet to be "too big to be decrypted". Do you > > mean > > > that the decrypted payload is too big to > > deliver on > > > the next link? > > > > > > > > > > > > --Ben Schwartz > > > > > > > > > > > > From: IPsec <ipsec-boun...@ietf.org> on behalf > > of > > > Daniel Migault <mglt.i...@gmail.com> > > > Sent: Thursday, July 27, 2023 9:32 PM > > > To: IPsecME WG <ipsec@ietf.org> > > > Subject: [IPsec] -ikev2-mtu-dect: IKEv2 PTB > > > Notification > > > > > > > > > > > > In yesterday's presentation of the > > -ikev2-mtu-dect > > > draft, I was asked why do we have such a > > notification > > > instead of using a standard ICMP PTB message > > > encapsulated in ESP. I believe the confusion > > comes > > > from me saying that the PTB message > > > > > > In yesterday's presentation of the > > -ikev2-mtu-dect > > > draft, I was asked why do we have such a > > notification > > > instead of using a standard ICMP PTB message > > > encapsulated in ESP. > > > > > > > > > > > > I believe the confusion comes from me saying > > that the > > > PTB message is sent AFTER the packet has been > > > decrypted. This is not the case as the PTB is > > sent > > > BECAUSE the encrypted packet is too big and so > > cannot > > > be decrypted. In other words the packet that is > > > too big is the ESP packet. > > > > > > > > > > > > If the packet is too big and cannot be > > decrypted a > > > Packet Too Big Notification (PTB) that > > specifies the > > > Link MTU (LMTU) of the router component of the > > egress > > > node (on network N) as well as the effective > > MTU to > > > receive (EMTU_R). Both are configuration > > parameters. > > > An ICMP PTB message may also be sent by the > > egress > > > node. Note that this ICMP may not contain even > > the > > > SPI, and so is likely to not carry sufficient > > > information to the ingress node, so any action > > be > > > taken. Typically the ICMP message only carries > > the > > > first 8 bytes start from IP header of the > > original > > > packets. This is not sufficient when > > encapsulated as > > > the 8 bytes will not contain the SPI and the > > egress > > > gateway will not be able to identify the > > concerned SA > > > and so the concerned flow. > > > > > > > > > > > > Yours, > > > Daniel > > > > > > > > > > > > > > > -- > > > > > > Daniel Migault > > > > > > Ericsson > > > > > > > > > > > > > > > -- > > > > > > Daniel Migault > > > > > > Ericsson > > > > > > > > > > > > -- > > > Daniel Migault > > > Ericsson > > > > > > > > > > > > -- > > > Daniel Migault > > > Ericsson > > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
