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

[Daniel Migault <[e-mail]>]

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 [e-mail] <[e-mail]>
wrote:

> On Oct 31, 2022, at 11:07 AM, Daniel Migault <[e-mail]> 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