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.
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
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
