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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

+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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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