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

[to...@strayalpha.com]

Hi, Daniel,

> On Jan 16, 2023, at 6:37 AM, Daniel Migault  wrote:
> ...
> On Sat, Jan 14, 2023 at 1:01 AM to...@strayalpha.com 
>   > wrote:
>> ...
>> However, that’s the issue. The reasons why what you’re trying to do isn’t 
>> useful is already covered in detail in intarea-tunnels - and why not to do 
>> it using IPv4 DF=0 in rfc6864. 
>> 
> rfc6864 provides requirements of IP ID. DF=1 for inner and outer packet 
> prevents using IP ID, but as mentioned DF=1 for outer is not possible in our 
> case

I’ve already explained how it is.

> and I am not sure we can enforce DF=1 in the inner packet as well. 

You don’t need to.

> Our proposal results in limiting fragmentation as well - when possible - and 
> as such makes these requirements easier to meet.

Any new use of DF=0 is directly against rfc6864 recommendations 
Additionally, you’re creating a new mechanism that is relevant only for IPv4; 
IPv6 has no DF=0 equivalent. That’s against current general advise not to focus 
on new IPv4-only approaches.

>> It’s not useful to have an email exchange rehashing that content message by 
>> message.
>> 
> The conversation has been clarifying to us - at least regarding the 
> terminology and we believe the document has improved, so that has been 
> somewhat useful and we thank you for these feedbacks.
> While DF=1 is the recommended way, it is not an option for us - unless proven 
> otherwise.

DF=0 requires you to enforce that you don’t reuse IDs during potential 
reassembly overlap, which requires knowing that AND setting the appropriate 
reassembly timeout at the receiver. You don’t do that so you don’t have a 
solution, IMO.

And DF=0 works only for IPv4, so that’s another reason you don’t have a 
solution. Any solution for IP should work for IPv6 first; if it also works (or 
doesn’t) for IPv4, that ought to be secondary at this point.

> **With DF=0**, we do measure some significant performance improvement by 
> using our proposal and so far, I have been able to see any reasons for not 
> doing it.

Improved performance only because you don’t check or enforce ID uniqueness. 

> If such reasons exist, it would be clarifying to explicitly mention them 
> explicitly (to me and the WG) so these could be considered..  

I have been explicit about these problems before as well.

Joe___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Daniel Migault]

Hi,

Thanks for the feedback. Please see below my comments/responses.

Yours,
Daniel
On Sat, Jan 14, 2023 at 1:01 AM to...@strayalpha.com 
wrote:

> Daniel,
>
> On Jan 13, 2023, at 8:33 PM, Daniel Migault  wrote:
>
> f not, to better understand, do we have an example of a packet that cannot
> be processed if the MTU is set to tunMAP but that can be processed if the
> MTU is set to EMTU_R.
>
>
> As per intarea-tunnels, MTU is a highly overloaded term.
>
> Tunnels relay packets that exceed their tunMAP but not their tunMTU
> (EMTU_R - headers) using source fragmentation all the time.
>

correct, we need to remove encaps.

However, that’s the issue. The reasons why what you’re trying to do isn’t
> useful is already covered in detail in intarea-tunnels - and why not to do
> it using IPv4 DF=0 in rfc6864.
>
> rfc6864 provides requirements of IP ID. DF=1 for inner and outer packet
prevents using IP ID, but as mentioned DF=1 for outer is not possible in
our case and I am not sure we can enforce DF=1 in the inner packet as
well. Our proposal results in limiting fragmentation as well - when
possible - and as such makes these requirements easier to meet.

It’s not useful to have an email exchange rehashing that content message by
> message.
>
> The conversation has been clarifying to us - at least regarding the
terminology and we believe the document has improved, so that has been
somewhat useful and we thank you for these feedbacks.
While DF=1 is the recommended way, it is not an option for us - unless
proven otherwise. **With DF=0**, we do measure some significant performance
improvement by using our proposal and so far, I have been able to see any
reasons for not doing it. If such reasons exist, it would be clarifying to
explicitly mention them explicitly (to me and the WG) so these could be
considered..


Joe
>


-- 
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

Daniel,

> On Jan 13, 2023, at 8:33 PM, Daniel Migault  wrote:
> 
> f not, to better understand, do we have an example of a packet that cannot be 
> processed if the MTU is set to tunMAP but that can be processed if the MTU is 
> set to EMTU_R. 


As per intarea-tunnels, MTU is a highly overloaded term.

Tunnels relay packets that exceed their tunMAP but not their tunMTU (EMTU_R - 
headers) using source fragmentation all the time.

However, that’s the issue. The reasons why what you’re trying to do isn’t 
useful is already covered in detail in intarea-tunnels - and why not to do it 
using IPv4 DF=0 in rfc6864.

It’s not useful to have an email exchange rehashing that content message by 
message.

Joe___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Daniel Migault]

Hi,

Thanks for the feedback, please find my comments and questions inline.

Yours,
Daniel

On Fri, Jan 13, 2023 at 8:41 PM to...@strayalpha.com 
wrote:

> Hi, Daniel,
>
> On Jan 13, 2023, at 2:12 PM, Daniel Migault  wrote:
>
> Hi Joe,
>
> Thanks for the comment. There are some terminologies we were not using
> properly, so thank you for the clarification. Please find inline our
> clarification and implementation of your concerns.
>
> Yours,
> Daniel
>
> On Sun, Jan 8, 2023 at 11:45 AM to...@strayalpha.com 
> wrote:
>
>> Hi, Daniel,
>>
>> The abstract clearly states a goal that is not achievable (of avoiding
>> reassembly). The best way to avoid the impact of mid-tunnel fragmentation
>> is to use IPv4 as a tunnel header the way that IPv6 would be - with DF=1.
>> However, even so, the egress always needs to handle reasssembly as long as
>> there is even source fragmentation.
>>
>
> I understand the comment as our goal is interpreted to avoid
> reassembling operations to happen completely. This would mean that
> reassembly could even not be implemented.
> This is not our intention. Reassembly happens the same way it happens
> today. The only thing we do is that the egress node notify the ingress node
> that reassembly is happening. The ingress node may or may not take any
> action to prevent reassembly to happen with the next packets being tunneled
> over the IPsec tunnel. In that sense "avoid" needs to be understood as
> reducing the number of occurrences the reassembly operation happens.
>
> We may agree the best way to avoid mid tunnel fragmentation is to set
> DF=1. But in our case we cannot meet this condition.
> The current text in the abstract is
>
> OLD:
> This document considers an ingress and an egress security gateway
> connected over an IPv4 network.
> The Tunnel Link Packet have their Don't Fragment (DF) set to 0.
>
> Does the text below is clearer to say:
>
> NEW:
> This document considers an ingress and an egress security gateway
> connected over a IPv4 network with the Tunnel Link Packet Don't Fragment
> (DF) set to 0.
>
>
> That is better English, but still technically ill-advised. Any solution
> that requires IPv4 DF=0 then requires generation of unique IDs that don’t
> wrap in ways that could cause mis-reassembly per RFC 6864.
>
> The introduction mentions the rationals on why we cannot rely on setting
> DF=1. Typically some routers do not check the MTU and ignore the packet
> without returning a ICMP PTB error and in many deployments the ICMP PTB -if
> sent - is blocked and is not received. This prohibits the use of DF=1 with
> IPv4.
>
>
> You have described the reason why PLPMTUD exists, which is not a rationale
> for continuing to use on-path IPv4 fragmentation.
>

>
>> I appreciate what you WANT to do - but again, it is not possible. You
>> have two behaviors - either use inner fragmentation (which won’t work for
>> transit traffic where IPv4 DF=1 or any IPv6) or reduce the tunnel MTU.
>>
>> But the tunnel MTU is defined by EMTU_R of the tunnel egress, not EMTU_S
>> of the tunnel ingress. If you reduce the tunnel MTU, you’re just going to
>> end up black-holing packets arriving at the tunnel ingress.
>>
>>  ok. I misunderstood tunnel MTU and that tunnel MTU is EMTU_R, this is
> not what we are changing. What we had written might be confusing.
> When I said EMTU_R I was considering the router only without any
> consideration of the tunnel.  From the terminology section of
> intarea-tunnel I did not read EMTU_R applies to a tunnel environment, and
> considered this to be the MTU associated to the interface for incoming
> packet to the router.
>
> Here is what we actually meant:
>
>
> We are ensuring that packet that are encapsulated by the Ingress interface
> do not exceed the tunnel MAP.  My understanding is  that the tunnel MAP is
> the largest IP packet the source can send,  that will not be fragmented by
> the network between the Ingress and egress interface. As it is not
> fragmented, fragments will not be reassembled.
>
>
> Please review intarea-tunnels.
>
> Setting Ingress send size to MAP doesn’t avoid source fragmentation, which
> thus doesn’t avoid reassembly. It just sets the size of each fragment to
> avoid on-path fragmentation - which avoids the need for DF=0. So setting
> DF=0 is exactly what you don’t need.
>
> To do so, we set the MTU of the router associated with the Ingress
> interface is set to the tunnel MAP. This corresponds to set tunMTU =tunMAP
> Figure 11 of intarea.
>
> Suppose an IP packet is sent by the source and meets that router.
> * The packet has DF=1. If it is larger than that MTU (= tunMAP), the
> packet is discarded and an ICMP PTB message is sent back to the source. The
> source will proceed to source fragmentation.
>
>
> When the IP packet gets to the router, the link should have an MTU of the
> tiunnel EMTU_R, not MAP.
>
I agree that setting the MTU to EMTU_R is the largest possible value.
However, setting it to a smaller value may also  be 

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

[to...@strayalpha.com]

Hi, Daniel,

> On Jan 13, 2023, at 2:12 PM, Daniel Migault  wrote:
> 
> Hi Joe,
> 
> Thanks for the comment. There are some terminologies we were not using 
> properly, so thank you for the clarification. Please find inline our 
> clarification and implementation of your concerns.
> 
> Yours, 
> Daniel  
> 
> On Sun, Jan 8, 2023 at 11:45 AM to...@strayalpha.com 
>   > wrote:
>> Hi, Daniel,
>> 
>> The abstract clearly states a goal that is not achievable (of avoiding 
>> reassembly). The best way to avoid the impact of mid-tunnel fragmentation is 
>> to use IPv4 as a tunnel header the way that IPv6 would be - with DF=1. 
>> However, even so, the egress always needs to handle reasssembly as long as 
>> there is even source fragmentation.
>  
> I understand the comment as our goal is interpreted to avoid reassembling 
> operations to happen completely. This would mean that reassembly could even 
> not be implemented. 
> This is not our intention. Reassembly happens the same way it happens today. 
> The only thing we do is that the egress node notify the ingress node that 
> reassembly is happening. The ingress node may or may not take any action to 
> prevent reassembly to happen with the next packets being tunneled over the 
> IPsec tunnel. In that sense "avoid" needs to be understood as reducing the 
> number of occurrences the reassembly operation happens.  
> 
> We may agree the best way to avoid mid tunnel fragmentation is to set DF=1. 
> But in our case we cannot meet this condition. 
> The current text in the abstract is
> 
> OLD:
> This document considers an ingress and an egress security gateway connected 
> over an IPv4 network.
> The Tunnel Link Packet have their Don't Fragment (DF) set to 0.
> 
> Does the text below is clearer to say:
> 
> NEW:
> This document considers an ingress and an egress security gateway connected 
> over a IPv4 network with the Tunnel Link Packet Don't Fragment (DF) set to 0.

That is better English, but still technically ill-advised. Any solution that 
requires IPv4 DF=0 then requires generation of unique IDs that don’t wrap in 
ways that could cause mis-reassembly per RFC 6864.

> The introduction mentions the rationals on why we cannot rely on setting 
> DF=1. Typically some routers do not check the MTU and ignore the packet 
> without returning a ICMP PTB error and in many deployments the ICMP PTB -if 
> sent - is blocked and is not received. This prohibits the use of DF=1 with 
> IPv4. 

You have described the reason why PLPMTUD exists, which is not a rationale for 
continuing to use on-path IPv4 fragmentation.

>> 
>> I appreciate what you WANT to do - but again, it is not possible. You have 
>> two behaviors - either use inner fragmentation (which won’t work for transit 
>> traffic where IPv4 DF=1 or any IPv6) or reduce the tunnel MTU.
>> 
>> But the tunnel MTU is defined by EMTU_R of the tunnel egress, not EMTU_S of 
>> the tunnel ingress. If you reduce the tunnel MTU, you’re just going to end 
>> up black-holing packets arriving at the tunnel ingress.
>> 
>  ok. I misunderstood tunnel MTU and that tunnel MTU is EMTU_R, this is not 
> what we are changing. What we had written might be confusing. 
> When I said EMTU_R I was considering the router only without any 
> consideration of the tunnel.  From the terminology section of intarea-tunnel 
> I did not read EMTU_R applies to a tunnel environment, and considered this to 
> be the MTU associated to the interface for incoming packet to the router.
> 
> Here is what we actually meant:
> 
> 
> We are ensuring that packet that are encapsulated by the Ingress interface do 
> not exceed the tunnel MAP.  My understanding is  that the tunnel MAP is the 
> largest IP packet the source can send,  that will not be fragmented by the 
> network between the Ingress and egress interface. As it is not fragmented, 
> fragments will not be reassembled.

Please review intarea-tunnels.

Setting Ingress send size to MAP doesn’t avoid source fragmentation, which thus 
doesn’t avoid reassembly. It just sets the size of each fragment to avoid 
on-path fragmentation - which avoids the need for DF=0. So setting DF=0 is 
exactly what you don’t need.

> To do so, we set the MTU of the router associated with the Ingress interface 
> is set to the tunnel MAP. This corresponds to set tunMTU =tunMAP  Figure 11 
> of intarea. 
> 
> Suppose an IP packet is sent by the source and meets that router. 
> * The packet has DF=1. If it is larger than that MTU (= tunMAP), the packet 
> is discarded and an ICMP PTB message is sent back to the source. The source 
> will proceed to source fragmentation. 

When the IP packet gets to the router, the link should have an MTU of the 
tiunnel EMTU_R, not MAP.

If the packet arrives with DF=1, then if it’s smaller than the tunnel EMTU_R, 
it will pass. If not, the router has no choice but to drop the packet (and try 
to send an ICMP PTB if that’s possible).

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

[Daniel Migault]

Hi Joe,

Thanks for the comment. There are some terminologies we were not using
properly, so thank you for the clarification. Please find inline our
clarification and implementation of your concerns.

Yours,
Daniel

On Sun, Jan 8, 2023 at 11:45 AM to...@strayalpha.com 
wrote:

> Hi, Daniel,
>
> The abstract clearly states a goal that is not achievable (of avoiding
> reassembly). The best way to avoid the impact of mid-tunnel fragmentation
> is to use IPv4 as a tunnel header the way that IPv6 would be - with DF=1.
> However, even so, the egress always needs to handle reasssembly as long as
> there is even source fragmentation.
>

I understand the comment as our goal is interpreted to avoid
reassembling operations to happen completely. This would mean that
reassembly could even not be implemented.
This is not our intention. Reassembly happens the same way it happens
today. The only thing we do is that the egress node notify the ingress node
that reassembly is happening. The ingress node may or may not take any
action to prevent reassembly to happen with the next packets being tunneled
over the IPsec tunnel. In that sense "avoid" needs to be understood as
reducing the number of occurrences the reassembly operation happens.

We may agree the best way to avoid mid tunnel fragmentation is to set DF=1.
But in our case we cannot meet this condition.
The current text in the abstract is

OLD:
This document considers an ingress and an egress security gateway connected
over an IPv4 network.
The Tunnel Link Packet have their Don't Fragment (DF) set to 0.

Does the text below is clearer to say:

NEW:
This document considers an ingress and an egress security gateway connected
over a IPv4 network with the Tunnel Link Packet Don't Fragment (DF) set to
0.

The introduction mentions the rationals on why we cannot rely on setting
DF=1. Typically some routers do not check the MTU and ignore the packet
without returning a ICMP PTB error and in many deployments the ICMP PTB -if
sent - is blocked and is not received. This prohibits the use of DF=1 with
IPv4.



>
> I appreciate what you WANT to do - but again, it is not possible. You have
> two behaviors - either use inner fragmentation (which won’t work for
> transit traffic where IPv4 DF=1 or any IPv6) or reduce the tunnel MTU.
>
> But the tunnel MTU is defined by EMTU_R of the tunnel egress, not EMTU_S
> of the tunnel ingress. If you reduce the tunnel MTU, you’re just going to
> end up black-holing packets arriving at the tunnel ingress.
>
>  ok. I misunderstood tunnel MTU and that tunnel MTU is EMTU_R, this is not
what we are changing. What we had written might be confusing.
When I said EMTU_R I was considering the router only without any
consideration of the tunnel.  From the terminology section of
intarea-tunnel I did not read EMTU_R applies to a tunnel environment, and
considered this to be the MTU associated to the interface for incoming
packet to the router.

Here is what we actually meant:


We are ensuring that packet that are encapsulated by the Ingress interface
do not exceed the tunnel MAP.  My understanding is  that the tunnel MAP is
the largest IP packet the source can send,  that will not be fragmented by
the network between the Ingress and egress interface. As it is not
fragmented, fragments will not be reassembled.

To do so, we set the MTU of the router associated with the Ingress
interface is set to the tunnel MAP. This corresponds to set tunMTU =tunMAP
Figure 11 of intarea.

Suppose an IP packet is sent by the source and meets that router.
* The packet has DF=1. If it is larger than that MTU (= tunMAP), the packet
is discarded and an ICMP PTB message is sent back to the source. The source
will proceed to source fragmentation.

* The packet has DF=0.  that is larger than that MTU the router fragments
it in fragments less than tunMAP thus performing inner fragmentation.

* Any packet smaller than the MTU = tunMAP is sent to the ingress interface
and encapsulated.


I agree that we MUST ensure that ICMP PTB messages are received by the
source and lead to source fragmentation otherwise, this will result in
black holding traffic between the tunnel MAP and the original MTU of the
router.

Note that by setting DF=1 you are supposed to be able to handle this kind
of situation. So I do not see this as a major issue.

Two important points: the tunnel ingress is NOT the one that should ever
> send PTB back; that’s the job of the router where/if that tunnel ingress
> resides; second, you cannot claim to get around an ICMP black hole
> situation by creating a new ICMP black hole situation.
>
> With the mechanism we clarified, the ICMP PTB is sent by the router where
the ingress interface is.
Regarding the blackholing situation, in the first case, it results from the
transit network which is out of the control of the administrator of the
source. On the other hand, the administrator of the source is able to
ensure that ICMP packet sent by the ingress router will be 

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

[to...@strayalpha.com]

Hi, Daniel,

The abstract clearly states a goal that is not achievable (of avoiding 
reassembly). The best way to avoid the impact of mid-tunnel fragmentation is to 
use IPv4 as a tunnel header the way that IPv6 would be - with DF=1. However, 
even so, the egress always needs to handle reasssembly as long as there is even 
source fragmentation.

I appreciate what you WANT to do - but again, it is not possible. You have two 
behaviors - either use inner fragmentation (which won’t work for transit 
traffic where IPv4 DF=1 or any IPv6) or reduce the tunnel MTU.

But the tunnel MTU is defined by EMTU_R of the tunnel egress, not EMTU_S of the 
tunnel ingress. If you reduce the tunnel MTU, you’re just going to end up 
black-holing packets arriving at the tunnel ingress.

Two important points: the tunnel ingress is NOT the one that should ever send 
PTB back; that’s the job of the router where/if that tunnel ingress resides; 
second, you cannot claim to get around an ICMP black hole situation by creating 
a new ICMP black hole situation.

The rest of the document is rife with further errors, e.g.:

The last sentence of the abstract is incomprehensible. 

In the intro, the claims about IPv4 ID are incorrect. As noted in RFC6864, 
speed is not the issue but rather the expected reordering. Additionally, 
there’s already a timeout, so there is no requirement for indefinitely kept 
state. Further, given source fragmentation, such issues are irrelevant.

DF=1 leads to black holing ONLY in the absence of PLPMTUD, which is the 
appropriate solution for IPsec tunnels anyway. Note that even if DF=0, 
black-holing could still occur if the Tunnel Transit packet exceeds the tunnel 
egress EMTU_R.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Jan 4, 2023, at 7:21 PM, Daniel Migault  wrote:
> 
> Hi Joe, 
> 
> We are waiting for your feedback, but I just want to check we have the same 
> understanding and that we will have a feed back.
>   
> We would like to understand if the terminology used in the document is 
> aligned with the one of intarea-tunnels and if we agree that intarea-tunnels 
> and IPsec have different perspectives on handling fragmentation. I do not see 
> what we are proposing very different from what IPsec has been doing for 
> years.  
> 
> I also think that everything is explained in the introduction (2 text pages), 
> so you do not have to read the full document. The document is available here:
> https://datatracker.ietf.org/doc/draft-liu-ipsecme-ikev2-mtu-dect/
> 
> Yours, 
> Daniel
> 
> On Sat, Nov 26, 2022 at 9:25 AM Daniel Migault  > wrote:
>> Hi Joe, 
>> 
>> So  we just published an update of our draft. We try to catch up the 
>> complete idea in the introduction - to avoid reading the complete draft. I 
>> think we partly aligned with the tunnel document. The current version only 
>> describe the security gateway as a node and does not split it between a 
>> outer and an interface. I think for the remaining of the document we are 
>> taking the exact terminology from the tunnel draft.
>> 
>> We believe that IKEv2 and the tunnel document have different visions and 
>> tried to highlight this also. 
>> 
>> One big clarification in my point of view is that the previous version 
>> confused MTU with MAP. 
>> 
>> We are happy to get your feedback. 
>> 
>> Yours, 
>> Daniel
>> 
>> On Mon, Oct 31, 2022 at 5:32 PM to...@strayalpha.com 
>>  > > wrote:
>>> On Oct 31, 2022, at 11:07 AM, Daniel Migault >> > wrote:
 
>   - the tunnel has two DIFFERENT relevant MTUs
>   the egress reassembly MTU (EMTU_R), which is the only thing 
> that should drive the “tunnel MTU”
> 
>   the tunnel MTU, which the ingress needs to know for source 
> fragmentation, but is NOT relevant to the
>   origin MTU upstream of the ingress
> 
 Will read the draft - but we believe that is better to generate one IPsec 
 packet for every inner IP packet as opposed to two. This is why we are 
 proposing to adjust the MTU so the outer packet matches the limit of the 
 EMTU_R - and fragmentation be avoided.
>>> 
>>> That doc explains why this is effort isn’t useful. As I noted to Tero, 
>>> there’s no ICMP message that says “bigger than I’d like”. PTB means 
>>> “packets larger than this will be dropped”. That’s not what’s going on 
>>> here, so it’s the wrong message to support.
>>> 
>>> There is no message that supports what you’re trying to do - perhaps 
>>> because there can’t and shouldn’t be.
>>> 
>>> Joe
>> 
>> 
>> -- 
>> Daniel Migault
>> Ericsson
> 
> 
> -- 
> Daniel Migault
> Ericsson
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org

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

[Daniel Migault]

Hi Joe,

We are waiting for your feedback, but I just want to check we have the same
understanding and that we will have a feed back.

We would like to understand if the terminology used in the document is
aligned with the one of intarea-tunnels and if we agree that
intarea-tunnels and IPsec have different perspectives on
handling fragmentation. I do not see what we are proposing very different
from what IPsec has been doing for years.

I also think that everything is explained in the introduction (2 text
pages), so you do not have to read the full document. The document is
available here:
https://datatracker.ietf.org/doc/draft-liu-ipsecme-ikev2-mtu-dect/

Yours,
Daniel

On Sat, Nov 26, 2022 at 9:25 AM Daniel Migault  wrote:

> Hi Joe,
>
> So  we just published an update of our draft. We try to catch up the
> complete idea in the introduction - to avoid reading the complete draft. I
> think we partly aligned with the tunnel document. The current version only
> describe the security gateway as a node and does not split it between a
> outer and an interface. I think for the remaining of the document we are
> taking the exact terminology from the tunnel draft.
>
> We believe that IKEv2 and the tunnel document have different visions and
> tried to highlight this also.
>
> One big clarification in my point of view is that the previous version
> confused MTU with MAP.
>
> We are happy to get your feedback.
>
> Yours,
> Daniel
>
> On Mon, Oct 31, 2022 at 5:32 PM to...@strayalpha.com 
> wrote:
>
>> On Oct 31, 2022, at 11:07 AM, Daniel Migault  wrote:
>>
>>
>> - the tunnel has two DIFFERENT relevant MTUs
>>> the egress reassembly MTU (EMTU_R), which is the only thing that should
>>> drive the “tunnel MTU”
>>>
>>> the tunnel MTU, which the ingress needs to know for source
>>> fragmentation, but is NOT relevant to the
>>> origin MTU upstream of the ingress
>>>
>>> Will read the draft - but we believe that is better to generate one
>> IPsec packet for every inner IP packet as opposed to two. This is why we
>> are proposing to adjust the MTU so the outer packet matches the limit of
>> the EMTU_R - and fragmentation be avoided.
>>
>>
>> That doc explains why this is effort isn’t useful. As I noted to Tero,
>> there’s no ICMP message that says “bigger than I’d like”. PTB means
>> “packets larger than this will be dropped”. That’s not what’s going on
>> here, so it’s the wrong message to support.
>>
>> There is no message that supports what you’re trying to do - perhaps
>> because there can’t and shouldn’t be.
>>
>> Joe
>>
>
>
> --
> Daniel Migault
> Ericsson
>


-- 
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Daniel Migault]

Hi all,

We proposed Joe to become a co-author, he refused as he said the review was
done in his capacity of TSV area review and asked us to post this on the
mailing list.

Yours,
Daniel

On Sat, Nov 26, 2022 at 9:25 AM Daniel Migault  wrote:

> Hi Joe,
>
> So  we just published an update of our draft. We try to catch up the
> complete idea in the introduction - to avoid reading the complete draft. I
> think we partly aligned with the tunnel document. The current version only
> describe the security gateway as a node and does not split it between a
> outer and an interface. I think for the remaining of the document we are
> taking the exact terminology from the tunnel draft.
>
> We believe that IKEv2 and the tunnel document have different visions and
> tried to highlight this also.
>
> One big clarification in my point of view is that the previous version
> confused MTU with MAP.
>
> We are happy to get your feedback.
>
> Yours,
> Daniel
>
> On Mon, Oct 31, 2022 at 5:32 PM to...@strayalpha.com 
> wrote:
>
>> On Oct 31, 2022, at 11:07 AM, Daniel Migault  wrote:
>>
>>
>> - the tunnel has two DIFFERENT relevant MTUs
>>> the egress reassembly MTU (EMTU_R), which is the only thing that should
>>> drive the “tunnel MTU”
>>>
>>> the tunnel MTU, which the ingress needs to know for source
>>> fragmentation, but is NOT relevant to the
>>> origin MTU upstream of the ingress
>>>
>>> Will read the draft - but we believe that is better to generate one
>> IPsec packet for every inner IP packet as opposed to two. This is why we
>> are proposing to adjust the MTU so the outer packet matches the limit of
>> the EMTU_R - and fragmentation be avoided.
>>
>>
>> That doc explains why this is effort isn’t useful. As I noted to Tero,
>> there’s no ICMP message that says “bigger than I’d like”. PTB means
>> “packets larger than this will be dropped”. That’s not what’s going on
>> here, so it’s the wrong message to support.
>>
>> There is no message that supports what you’re trying to do - perhaps
>> because there can’t and shouldn’t be.
>>
>> Joe
>>
>
>
> --
> Daniel Migault
> Ericsson
>


-- 
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Daniel Migault]

Hi Joe,

So  we just published an update of our draft. We try to catch up the
complete idea in the introduction - to avoid reading the complete draft. I
think we partly aligned with the tunnel document. The current version only
describe the security gateway as a node and does not split it between a
outer and an interface. I think for the remaining of the document we are
taking the exact terminology from the tunnel draft.

We believe that IKEv2 and the tunnel document have different visions and
tried to highlight this also.

One big clarification in my point of view is that the previous version
confused MTU with MAP.

We are happy to get your feedback.

Yours,
Daniel

On Mon, Oct 31, 2022 at 5:32 PM to...@strayalpha.com 
wrote:

> On Oct 31, 2022, at 11:07 AM, Daniel Migault  wrote:
>
>
> - the tunnel has two DIFFERENT relevant MTUs
>> the egress reassembly MTU (EMTU_R), which is the only thing that should
>> drive the “tunnel MTU”
>>
>> the tunnel MTU, which the ingress needs to know for source fragmentation,
>> but is NOT relevant to the
>> origin MTU upstream of the ingress
>>
>> Will read the draft - but we believe that is better to generate one IPsec
> packet for every inner IP packet as opposed to two. This is why we are
> proposing to adjust the MTU so the outer packet matches the limit of the
> EMTU_R - and fragmentation be avoided.
>
>
> That doc explains why this is effort isn’t useful. As I noted to Tero,
> there’s no ICMP message that says “bigger than I’d like”. PTB means
> “packets larger than this will be dropped”. That’s not what’s going on
> here, so it’s the wrong message to support.
>
> There is no message that supports what you’re trying to do - perhaps
> because there can’t and shouldn’t be.
>
> Joe
>


-- 
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

On Oct 31, 2022, at 11:07 AM, Daniel Migault  wrote:
> 
>>  - the tunnel has two DIFFERENT relevant MTUs
>>  the egress reassembly MTU (EMTU_R), which is the only thing 
>> that should drive the “tunnel MTU”
>> 
>>  the tunnel MTU, which the ingress needs to know for source 
>> fragmentation, but is NOT relevant to the
>>  origin MTU upstream of the ingress
>> 
> Will read the draft - but we believe that is better to generate one IPsec 
> packet for every inner IP packet as opposed to two. This is why we are 
> proposing to adjust the MTU so the outer packet matches the limit of the 
> EMTU_R - and fragmentation be avoided.

That doc explains why this is effort isn’t useful. As I noted to Tero, there’s 
no ICMP message that says “bigger than I’d like”. PTB means “packets larger 
than this will be dropped”. That’s not what’s going on here, so it’s the wrong 
message to support.

There is no message that supports what you’re trying to do - perhaps because 
there can’t and shouldn’t be.

Joe___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

> On Oct 31, 2022, at 1:23 PM, Tero Kivinen  wrote:
> 
> to...@strayalpha.com writes:
>> 
>> What SHOULD happen in IPsec is that the SPI should have an MTU
>> (being a link) and the *router* where packets are forwarded into the
>> tunnel should determine when packets that want to enter that link
>> are too big - at which point, per RFC 1812, the *router* should be
>> sending the ICMP.
> 
> This is what the RFC4301 describes if I understood your description
> correctly. ...
> 
> So I think IPsec is still doing everything correctly.

For PTBs received along the path, then yes.

There are a few different cases here:
- the reassembled tunnel packet is decrypted, decapsulated, and inside 
is an IPv4 DF=1 that exceeds the next-hop MTU
at which point the IPsec tunnel egress router sends ICMP PTB 
based on that decapsulated (origin) packet (or not)

- the tunnel hops generated a PTB to the IPsec ingress, which changes 
its MTU
and the router at that ingress router sends PTBs back on 
subsequent packets if they receive IPv4 DF=1 that exceed that MTU

- the egress reassembly fails because tunnel packet exceeds EMTU_R at 
the egress
there’s no ICMP for this message, however

The PTBs of the tunnel (middle case) change the fragment size emitted from the 
ingress  (EMTU_S) accordingly, but it would not cause the tunnel to fail.

But note that the tunnel MTU is not its path MTU; it is the EMTU_R of the 
tunnel. Other packets CAN traverse it. So the only MTU the IPsec ingress should 
ever send back in a PTB would be EMTU_R of the tunnel.

This document tries to get around the fact that ICMP has no “packet bigger than 
I’d like” signal.

(Yes, I realize this means tunnels need to do frag/reassemly and this is 
expensive; the reason is explained in intarea-tunnels. If you’re talking about 
tunnels then reading that doc is a prerequisite - at least to my further 
involvement)

Until that signal exists, calculating it and relaying it is not useful. Even 
then, using ICMP to do this makes no sense, esp. given the entire mechanism 
assumes ICMP doesn’t work over the tunnel path.

Joe

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Tero Kivinen]

to...@strayalpha.com writes:
> > The normal case to do that is that IPsec SGW keeps track of the size
> > of packets that are ok, and which are too big based on the information
> > it receives. I.e., it might have received unsecured ICMP PTB message
> > from the network for its own Child SA, but only knows the SPI of the
> > Child SA, not who was the original sender. So it keeps track that for
> > this SPI the ESP packets cannot be larger than xxx bytes.
> > 
> > Next time it receives a packet from the source and when it is
> > encrypting it, it will verify that it will fit the size set for that
> > Child SA, and if it is too big, it will generate ICMP PTB for that
> > specific packet.
> > 
> > IPsec gateways have been doing that for years, and this has been
> > described in the RFC4301 section 8.2.1.
> 
> That would happen because the tunnel packet caused PTB. This case is
> described in intarea-tunnels 4.3.2. The way in which IPsec gets it
> wrong (IMO) is described in Section 4.3.1 and is related to RFC
> 3884, e.g., by subsuming the functions of a router inside the IPsec
> mechanism, rather than operating strictly as a tunnel, which should
> be represented as a link - and *links do not send ICMP messages.
> 
> What SHOULD happen in IPsec is that the SPI should have an MTU
> (being a link) and the *router* where packets are forwarded into the
> tunnel should determine when packets that want to enter that link
> are too big - at which point, per RFC 1812, the *router* should be
> sending the ICMP.

This is what the RFC4301 describes if I understood your description
correctly. I.e., when SGW A (IPsec security gateway routing clear text
packets to encrypted tunnel) sends packets out having DF=1 and gets
ICMP PTB back from the route, it does not know which packet triggered
this event, as the ICMP PTB might not have enough data in it to
identify that. It should get the SPI and destination address, so it
should be able to associate that ICMP PTB to some Child SA.

Now it will store that information to that Child SA, and wait for next
packet to arrive, i.e., effectively setting the MTU of the link to
whatever ICMP PTB said (and taking in to account the overhead caused
by the IPsec). When packet that is too big for that tunnel it will
generate ICMP PTB just like router should. The difference there is
that this cannot happen on the first packet only for later packets.

So I think IPsec is still doing everything correctly.

This case is not about that it is when the incoming packets that does
not have DF set, and in that case the router can fragment them before
or after sending them to the tunnel. Quite typically they encrypt the
whole packet, and then fragment the resulting ESP packets, as that
makes it easier for the receiving end to the exit tunnel checks.

If the incoming frame was 1500 bytes and we added around 50 bytes of
IPsec overhead the resulting packet is 1550 bytes which gets fragment
to one 1500 byte fragment and one 50 byte fragment.

> > My understanding is that this draft (which I have not yet properly
> > read) is solving the situation where the tunnel does not get ICMP PTB
> > messages as they are forwarding packets with DF bit set to 0, and then
> > the receiving end will see extra fragmentation happening for the
> > packets. Then the receiving end will simulate the ICMP PTB by sending
> > authenticated IKEv2 notification that tells the sending end that his
> > packets got fragmented.
> 
> The only reason the packet would have been too big at the receiver
> is if it were to exceed the receiver’s reassembly buffer. That’s not
> what’s happening here.

Now if in the middle of the path there some other MTU in use, lets say
there is another IPsec tunnel there (tunnel in tunnel), and that
getway is fragmenting the incoming packet before sending it to the
tunnel (it could fragment it before putting it to tunnel, as the
packet was already fragmented so fragmenting it again does not matter,
or perhaps there some link between it and its destination which does
not support IP fragments). So it takes the 1500 byte fragment and
refragments that to 1420 byte and 80 byte fragments, and adds IPsec
overhead. Then when that tunnel is decapsulated away we have 3
fragments ending to the receiving node.

One is 1420 bytes, another is 80, and the last one is 50 bytes.

When the receiving SGW B will see this it most likely can know that
this was not original SGW A actually used, thus could report back to
the SGW A saying that SGW A should use MTU of 1420 bytes instead of
1500 when sending ESP packets over this route.

This is not really a PTB event as everything still works regardless
what SGW A and B do, but this is still not optimal behavior of the
tunnels, and it would be useful to detect and fix this situation. 

> It seems like there’s confusion about the fact that the source can
> somehow avoid fragmentation of the tunneled packets. That can’t
> happen - see intarea-tunnels Sec 3.6.3. Source fragmentation can 

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

[Daniel Migault]

Hi,

see below some clarifications.
On Mon, Oct 31, 2022 at 12:18 PM to...@strayalpha.com 
wrote:

> See below in-line.
>
> On Oct 31, 2022, at 8:53 AM, Daniel Migault  wrote:
>
>
>
> On Mon, Oct 31, 2022 at 11:25 AM to...@strayalpha.com <
> to...@strayalpha.com> wrote:
>
>> HI, Tero, et al,,
>>
>> Thanks for the clarification; I now understand that what you really are
>> seeking is PLPMTUD for IPsec, but somehow using on-path fragmentation as a
>> signal. That’s a mistake, IMO, largely because it serves only IPv4.
>>
>> My understanding is that IPv6 performs fragmentation at the source, in
> which case, the receiving gateway does not need to defragment.
>
>
> Both IPv4 and IPv6 use source fragmentation, which cannot be avoided for
> tunnels (see intarea-tunnels).
>
> There are two sources (please review intarea-tunnels); please explain more
> clearly which one you mean.
>
> The original source of the packet (outside the tunnel) does source
> fragmentation. This doesn’t impact the IPsec egress (please - not
> “receiving gateway” - that could refer to ANY router on the path, either
> outside the tunnel or inside the tunnel; note that it does NOT actually
> refer to the IPsec egress because IPsec could be implemented as “bump in
> the wire” and its endpoints might not be gateways at all).
>
> But *so does the IPsec ingress*. It fragments the tunnel packets (again,
> see intarea-tunnels). It is THOSE packets the IPsec egress reassembles.
>
> Our problem is only happening with IPv4 when an on-path router fragments
> and the receiving security gateway needs to re-fragment.
>
>
> You should already stop using on-path *TUNNEL* hop refragmentation (again,
> router here is ambiguous).
>
> The “receiving gateway” is the IPsec egress of this traffic. Why do you
> keep saying it needs to refragment? It *reassembles* the tunnel fragments
> (but it has to - source fragmentation is always possible and will always
> need to be supported).
>
> I agree we are not concerned by source fragmentation but by on-path
*TUNNEL* hop refragmentation. We know these should nor be used, but it is
used and we have to deal with it. This is the scope of our document.

> We explicitly mention in the introduction that what we have is not a
> PLPMTUD for IPsec.
>
>
> Understood. But here’s the issue:
>
> - the end-to-end path can and should be using PLPMTUD
> having your system find a way for IPsec ingresses to generate *more* ICMP
> PTBs is not a solution,
> as you already note (because they’re untrusted, dropped, or not generated
> in the first place)
>
> - the tunnel has two DIFFERENT relevant MTUs
> the egress reassembly MTU (EMTU_R), which is the only thing that should
> drive the “tunnel MTU”
>
> the tunnel MTU, which the ingress needs to know for source fragmentation,
> but is NOT relevant to the
> origin MTU upstream of the ingress
>
> Will read the draft - but we believe that is better to generate one IPsec
packet for every inner IP packet as opposed to two. This is why we are
proposing to adjust the MTU so the outer packet matches the limit of the
EMTU_R - and fragmentation be avoided.

Tunnels fragment and reassemble. There is no way to avoid that or to tune
> to that, *if you implement your tunnel properly, that fact is and needs to
> be invisible* to the endpoints.
>
> Or do you want your endpoints sending 48B payloads when you transit ATM
> links too (they do still exist)?
>
> Our understanding is that we are closer to ICMP-like than a PLPMTUD. Maybe
> a PLPMTUD can be built on top of it, but we would like to avoid taking that
> path for now.
>
>
> Please review intarea-tunnels. Signals inside the tunnel are not always
> appropriate to relay outside the tunnel.
>
> But the really confusing part here is that you admit that ICMP doesn’t
> work, but you’re designing a system to detect (the wrong) info to send in
> ICMPs.
>

What we are saying is that ICMP does not work because the message and its
information is *not* received - that is it is not generated, discarded and
in the best case not trusted. Using the IKEv2 channel achieves this.

The other part of the discussion is what to do once the gateway has that
information. We do list source fragmentation, which requires no interaction
with the peers sending the to-become-inner packet. On the other hand, we
believe - and maybe we are wrong - that it would be better to avoid the
fragmentation and ask the source of the inner packet to adjust its MTU and
send smaller packets. To do so we suggest using ICMP - which is the
trusted network. As the ICMP is coming from the IKEv2 gateway, it is
plausible that this packet reaches the source of the inner packet.






>
> Joe
>
>

-- 
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

See below in-line.

> On Oct 31, 2022, at 8:53 AM, Daniel Migault  wrote:
> 
> 
> 
> On Mon, Oct 31, 2022 at 11:25 AM to...@strayalpha.com 
>   > wrote:
>> HI, Tero, et al,,
>> 
>> Thanks for the clarification; I now understand that what you really are 
>> seeking is PLPMTUD for IPsec, but somehow using on-path fragmentation as a 
>> signal. That’s a mistake, IMO, largely because it serves only IPv4.
>> 
> My understanding is that IPv6 performs fragmentation at the source, in which 
> case, the receiving gateway does not need to defragment. 

Both IPv4 and IPv6 use source fragmentation, which cannot be avoided for 
tunnels (see intarea-tunnels).

There are two sources (please review intarea-tunnels); please explain more 
clearly which one you mean.

The original source of the packet (outside the tunnel) does source 
fragmentation. This doesn’t impact the IPsec egress (please - not “receiving 
gateway” - that could refer to ANY router on the path, either outside the 
tunnel or inside the tunnel; note that it does NOT actually refer to the IPsec 
egress because IPsec could be implemented as “bump in the wire” and its 
endpoints might not be gateways at all).

But *so does the IPsec ingress*. It fragments the tunnel packets (again, see 
intarea-tunnels). It is THOSE packets the IPsec egress reassembles. 

> Our problem is only happening with IPv4 when an on-path router fragments and 
> the receiving security gateway needs to re-fragment.

You should already stop using on-path *TUNNEL* hop refragmentation (again, 
router here is ambiguous).

The “receiving gateway” is the IPsec egress of this traffic. Why do you keep 
saying it needs to refragment? It *reassembles* the tunnel fragments (but it 
has to - source fragmentation is always possible and will always need to be 
supported).

> We explicitly mention in the introduction that what we have is not a  PLPMTUD 
> for IPsec.

Understood. But here’s the issue:

- the end-to-end path can and should be using PLPMTUD
having your system find a way for IPsec ingresses to generate 
*more* ICMP PTBs is not a solution,
as you already note (because they’re untrusted, dropped, or not 
generated in the first place)

- the tunnel has two DIFFERENT relevant MTUs
the egress reassembly MTU (EMTU_R), which is the only thing 
that should drive the “tunnel MTU”

the tunnel MTU, which the ingress needs to know for source 
fragmentation, but is NOT relevant to the
origin MTU upstream of the ingress

Tunnels fragment and reassemble. There is no way to avoid that or to tune to 
that, *if you implement your tunnel properly, that fact is and needs to be 
invisible* to the endpoints.

Or do you want your endpoints sending 48B payloads when you transit ATM links 
too (they do still exist)?

> Our understanding is that we are closer to ICMP-like than a PLPMTUD. Maybe a 
> PLPMTUD can be built on top of it, but we would like to avoid taking that 
> path for now. 

Please review intarea-tunnels. Signals inside the tunnel are not always 
appropriate to relay outside the tunnel.

But the really confusing part here is that you admit that ICMP doesn’t work, 
but you’re designing a system to detect (the wrong) info to send in ICMPs.

Joe

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Daniel Migault]

So to clarify, the draft is mostly carrying the necessary information so
the gateway can deal with fragmentation in its network using whatever means
is needed.
The use of ICMP PTB was only a suggestion, other mechanisms may be used.
The definition of such a mechanism is outside of ipsec and the draft.
Our understanding is that unless there is no such mechanism the draft has
some value.

Yours,
Daniel


On Mon, Oct 31, 2022 at 11:59 AM Joe Touch  wrote:

> +1
>
> > On Oct 31, 2022, at 8:37 AM, Michael Richardson 
> wrote:
> >
> > 
> > Tero Kivinen  wrote:
> >> My understanding is that this draft (which I have not yet properly
> >> read) is solving the situation where the tunnel does not get ICMP PTB
> >> messages as they are forwarding packets with DF bit set to 0, and then
> >> the receiving end will see extra fragmentation happening for the
> >> packets. Then the receiving end will simulate the ICMP PTB by sending
> >> authenticated IKEv2 notification that tells the sending end that his
> >> packets got fragmented.
> >
> > While I think that the authors think they are solving this problem, I
> think
> > that what they have created is a protocol for dealing with fragmentation
> > beyond the far gateway.
> >
> > --
> > Michael Richardson , Sandelman Software Works
> > -= IPv6 IoT consulting =-
> >
> >
> >
> > ___
> > 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
>


-- 
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Daniel Migault]

I think Michael is correct. The problem comes from the fragmentation of the
outer IPv4 packet. The inner packet might be IPv4 or IPv6 and the
security gateway may use any possible means to ask the nodes to adjust
their MTU. Currently we suggest using ICMP PTB, but if  RFC9268 also
provides some means to do it, we do not want to prevent using it. We
currently believe that this may be up to the gateway to decide what to do,
so we do not necessarily require any use mechanism to be normative - but
that point may evolve depending on what the WG decides.

Yours,
Daniel

On Mon, Oct 31, 2022 at 11:37 AM Michael Richardson 
wrote:

>
> Tero Kivinen  wrote:
> > My understanding is that this draft (which I have not yet properly
> > read) is solving the situation where the tunnel does not get ICMP PTB
> > messages as they are forwarding packets with DF bit set to 0, and
> then
> > the receiving end will see extra fragmentation happening for the
> > packets. Then the receiving end will simulate the ICMP PTB by sending
> > authenticated IKEv2 notification that tells the sending end that his
> > packets got fragmented.
>
> While I think that the authors think they are solving this problem, I think
> that what they have created is a protocol for dealing with fragmentation
> beyond the far gateway.
>
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
> ___
> IPsec mailing list
> 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

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

[Joe Touch]

+1

> On Oct 31, 2022, at 8:37 AM, Michael Richardson  wrote:
> 
> 
> Tero Kivinen  wrote:
>> My understanding is that this draft (which I have not yet properly
>> read) is solving the situation where the tunnel does not get ICMP PTB
>> messages as they are forwarding packets with DF bit set to 0, and then
>> the receiving end will see extra fragmentation happening for the
>> packets. Then the receiving end will simulate the ICMP PTB by sending
>> authenticated IKEv2 notification that tells the sending end that his
>> packets got fragmented.
> 
> While I think that the authors think they are solving this problem, I think
> that what they have created is a protocol for dealing with fragmentation
> beyond the far gateway.
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> ___
> 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

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

[Daniel Migault]

On Mon, Oct 31, 2022 at 11:25 AM to...@strayalpha.com 
wrote:

> HI, Tero, et al,,
>
> Thanks for the clarification; I now understand that what you really are
> seeking is PLPMTUD for IPsec, but somehow using on-path fragmentation as a
> signal. That’s a mistake, IMO, largely because it serves only IPv4.
>
> My understanding is that IPv6 performs fragmentation at the source, in
which case, the receiving gateway does not need to defragment.  Our problem
is only happening with IPv4 when an on-path router fragments and the
receiving security gateway needs to re-fragment.

We explicitly mention in the introduction that what we have is not a
PLPMTUD for IPsec. Our understanding is that we are closer to ICMP-like
than a PLPMTUD. Maybe a PLPMTUD can be built on top of it, but we would
like to avoid taking that path for now.


> To the authors, again please see intarea-tunnels. The terms used here are
> ambiguous - “downstream” of a tunnel means traffic as it leaves the egress,
> but “downstream’ of the ingress could mean either that or the tunnel path
> itself (both are downstream).
>
> > On Oct 31, 2022, at 4:18 AM, Tero Kivinen  wrote:
> >
> > to...@strayalpha.com writes:
> >>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?
> >
> > The normal case to do that is that IPsec SGW keeps track of the size
> > of packets that are ok, and which are too big based on the information
> > it receives. I.e., it might have received unsecured ICMP PTB message
> > from the network for its own Child SA, but only knows the SPI of the
> > Child SA, not who was the original sender. So it keeps track that for
> > this SPI the ESP packets cannot be larger than xxx bytes.
> >
> > Next time it receives a packet from the source and when it is
> > encrypting it, it will verify that it will fit the size set for that
> > Child SA, and if it is too big, it will generate ICMP PTB for that
> > specific packet.
> >
> > IPsec gateways have been doing that for years, and this has been
> > described in the RFC4301 section 8.2.1.
>
> That would happen because the tunnel packet caused PTB. This case is
> described in intarea-tunnels 4.3.2. The way in which IPsec gets it wrong
> (IMO) is described in Section 4.3.1 and is related to RFC 3884, e.g., by
> subsuming the functions of a router inside the IPsec mechanism, rather than
> operating strictly as a tunnel, which should be represented as a link - and
> *links do not send ICMP messages.
>
> What SHOULD happen in IPsec is that the SPI should have an MTU (being a
> link) and the *router* where packets are forwarded into the tunnel should
> determine when packets that want to enter that link are too big - at which
> point, per RFC 1812, the *router* should be sending the ICMP.
>
> > My understanding is that this draft (which I have not yet properly
> > read) is solving the situation where the tunnel does not get ICMP PTB
> > messages as they are forwarding packets with DF bit set to 0, and then
> > the receiving end will see extra fragmentation happening for the
> > packets. Then the receiving end will simulate the ICMP PTB by sending
> > authenticated IKEv2 notification that tells the sending end that his
> > packets got fragmented.
>
> The only reason the packet would have been too big at the receiver is if
> it were to exceed the receiver’s reassembly buffer. That’s not what’s
> happening here.
>
> It seems like there’s confusion about the fact that the source can somehow
> avoid fragmentation of the tunneled packets. That can’t happen - see
> intarea-tunnels Sec 3.6.3. Source fragmentation can and must still occur.
> The receiver should never send PTBs for 64-byte IPv4 packets (or 1280B
> IPv6).
>
> Further, on-path fragmentation for IPv4 has been warned against (the
> source has to rate-limit to avoid ID reuse during expected reordering, per
> RFC 6864).
>
> > Now the sending end can do similar processing of this information that
> > it does for unauthenticated ICMP PTB messages received for ESP
> > packets.
>
> Receiving a fragment isn’t a PTB event, though, as noted above.
>
> > --
> > kivi...@iki.fi
> >
> > ___
> > IPsec mailing list
> > 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

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

[Michael Richardson]

Tero Kivinen  wrote:
> My understanding is that this draft (which I have not yet properly
> read) is solving the situation where the tunnel does not get ICMP PTB
> messages as they are forwarding packets with DF bit set to 0, and then
> the receiving end will see extra fragmentation happening for the
> packets. Then the receiving end will simulate the ICMP PTB by sending
> authenticated IKEv2 notification that tells the sending end that his
> packets got fragmented.

While I think that the authors think they are solving this problem, I think
that what they have created is a protocol for dealing with fragmentation
beyond the far gateway.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

On Oct 31, 2022, at 5:17 AM, Michael Richardson  wrote:
> 
> 
> The other question is whether or not we can just leverage RFC9268 to do this.
> This is a recent 6man innovation.

You’d need to decide whether you are trying to fix IPv4 or IPv6 (this doc 
relies on IPv4) and whether you think RFC9268 headers will help or hurt the 
chances of your IPv6 packets getting through a net.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

HI, Tero, et al,,

Thanks for the clarification; I now understand that what you really are seeking 
is PLPMTUD for IPsec, but somehow using on-path fragmentation as a signal. 
That’s a mistake, IMO, largely because it serves only IPv4.

To the authors, again please see intarea-tunnels. The terms used here are 
ambiguous - “downstream” of a tunnel means traffic as it leaves the egress, but 
“downstream’ of the ingress could mean either that or the tunnel path itself 
(both are downstream).

> On Oct 31, 2022, at 4:18 AM, Tero Kivinen  wrote:
> 
> to...@strayalpha.com writes:
>>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?
> 
> The normal case to do that is that IPsec SGW keeps track of the size
> of packets that are ok, and which are too big based on the information
> it receives. I.e., it might have received unsecured ICMP PTB message
> from the network for its own Child SA, but only knows the SPI of the
> Child SA, not who was the original sender. So it keeps track that for
> this SPI the ESP packets cannot be larger than xxx bytes.
> 
> Next time it receives a packet from the source and when it is
> encrypting it, it will verify that it will fit the size set for that
> Child SA, and if it is too big, it will generate ICMP PTB for that
> specific packet.
> 
> IPsec gateways have been doing that for years, and this has been
> described in the RFC4301 section 8.2.1.

That would happen because the tunnel packet caused PTB. This case is described 
in intarea-tunnels 4.3.2. The way in which IPsec gets it wrong (IMO) is 
described in Section 4.3.1 and is related to RFC 3884, e.g., by subsuming the 
functions of a router inside the IPsec mechanism, rather than operating 
strictly as a tunnel, which should be represented as a link - and *links do not 
send ICMP messages.

What SHOULD happen in IPsec is that the SPI should have an MTU (being a link) 
and the *router* where packets are forwarded into the tunnel should determine 
when packets that want to enter that link are too big - at which point, per RFC 
1812, the *router* should be sending the ICMP.

> My understanding is that this draft (which I have not yet properly
> read) is solving the situation where the tunnel does not get ICMP PTB
> messages as they are forwarding packets with DF bit set to 0, and then
> the receiving end will see extra fragmentation happening for the
> packets. Then the receiving end will simulate the ICMP PTB by sending
> authenticated IKEv2 notification that tells the sending end that his
> packets got fragmented.

The only reason the packet would have been too big at the receiver is if it 
were to exceed the receiver’s reassembly buffer. That’s not what’s happening 
here.

It seems like there’s confusion about the fact that the source can somehow 
avoid fragmentation of the tunneled packets. That can’t happen - see 
intarea-tunnels Sec 3.6.3. Source fragmentation can and must still occur. The 
receiver should never send PTBs for 64-byte IPv4 packets (or 1280B IPv6).

Further, on-path fragmentation for IPv4 has been warned against (the source has 
to rate-limit to avoid ID reuse during expected reordering, per RFC 6864).

> Now the sending end can do similar processing of this information that
> it does for unauthenticated ICMP PTB messages received for ESP
> packets. 

Receiving a fragment isn’t a PTB event, though, as noted above. 

> -- 
> kivi...@iki.fi
> 
> ___
> 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

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

[Michael Richardson]

The other question is whether or not we can just leverage RFC9268 to do this.
This is a recent 6man innovation.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Tero Kivinen]

to...@strayalpha.com writes:
> 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?

The normal case to do that is that IPsec SGW keeps track of the size
of packets that are ok, and which are too big based on the information
it receives. I.e., it might have received unsecured ICMP PTB message
from the network for its own Child SA, but only knows the SPI of the
Child SA, not who was the original sender. So it keeps track that for
this SPI the ESP packets cannot be larger than xxx bytes.

Next time it receives a packet from the source and when it is
encrypting it, it will verify that it will fit the size set for that
Child SA, and if it is too big, it will generate ICMP PTB for that
specific packet.

IPsec gateways have been doing that for years, and this has been
described in the RFC4301 section 8.2.1.

My understanding is that this draft (which I have not yet properly
read) is solving the situation where the tunnel does not get ICMP PTB
messages as they are forwarding packets with DF bit set to 0, and then
the receiving end will see extra fragmentation happening for the
packets. Then the receiving end will simulate the ICMP PTB by sending
authenticated IKEv2 notification that tells the sending end that his
packets got fragmented.

Now the sending end can do similar processing of this information that
it does for unauthenticated ICMP PTB messages received for ESP
packets. 
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

> On Oct 30, 2022, at 6:33 PM, Daniel Migault  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 
>   > 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 

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

[Daniel Migault]

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 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 

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

[to...@strayalpha.com]

There are some issues with the doc:
- abstract has a typo, doc uses ’node’ where it should use ‘router’ for 
on-path frag, etc
- discussion should to be more specific with respect to RFCs 1122, 792, 
and 4821
- the overall problem is assumed but never clearly defined

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
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.

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.

I.e., this isn’t a signal from the egress to the ingress about the tunnel 
(path) MTU. 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).

What exactly is this a solution for?

Joe
—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec