Re: [IPsec] PLMTUD probes for IPsec
On Thu, May 10, 2018 at 10:21 PM, Paul Wouters wrote: > On Thu, 10 May 2018, Shibu wrote: > > PMTUD over IKE is needed anyways for large IKE cert payloads >> > > I don't agree. We can handle these with fragmentation now just fine. > > IKE Fragmentation internally utilize an MTU value - either the lowest MTU or the one discovered via PMTUD. If we use the lowest value of 1280 (say for v6) most of the link capacity (9k jumbo frames) is under utilized. This will have adverse effect on tunnel setup rate also. I think, PMTUD complements the IKE fragmentation use case, not the other way around, Isn't it ? However, one caveat with above approach is that there is an implicit >> assumption that paths for control and data traffic >> are same (i.e. IP based, 3 tupple paths). >> With SDWAN use cases (wherein paths could be orchestrated based on proto, >> port, QoS, App ID etc), would it be a precise >> assumption to make? How would we handle these cases when the paths are >> build for ESP and IKE differently? >> > > Right. UDP 4500 packets not starting with 4 zero bytes could be handled > differently. > > Thanks, Shibu. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] PLMTUD probes for IPsec
On Thu, 10 May 2018, Shibu wrote: PMTUD over IKE is needed anyways for large IKE cert payloads I don't agree. We can handle these with fragmentation now just fine. However, one caveat with above approach is that there is an implicit assumption that paths for control and data traffic are same (i.e. IP based, 3 tupple paths). With SDWAN use cases (wherein paths could be orchestrated based on proto, port, QoS, App ID etc), would it be a precise assumption to make? How would we handle these cases when the paths are build for ESP and IKE differently? Right. UDP 4500 packets not starting with 4 zero bytes could be handled differently. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] PLMTUD probes for IPsec
Shibu wrote: > PMTUD over IKE is needed anyways for large IKE cert payloads, so if we do > PMTUD over IKE, we could depend upon the same discovered MTU value for ESP > paths as well as a guidance value. This seems to work for most of the > cases, and there seems to be interest in the group towards this option. So > this looks to be a good option overall, if we tackle IKEv2 window nuances > effectively. I agree. This handles 90% of the cases, except for bigger more nuanced environments. > However, one caveat with above approach is that there is an implicit > assumption that paths for control and data traffic are same (i.e. IP > based, 3 tupple paths). > With SDWAN use cases (wherein paths could be orchestrated based on proto, > port, QoS, App ID etc), would it be a precise assumption to make? How > would we handle these cases when the paths are build for ESP and IKE > differently? I suggest that in such a situation, that *IKE* negotiate (probably just Notify's to announce actually) the existence of a TCP endpoint that is within the tunnel, and do PLMUTD over TCP across that to test things. In some situations the IKE daemon would be able to do the connection attempt itself, but in other situations, some other entity might have to do this. Much of this is a local implementation problem only the Notify needs to be standarized. There might be IPv6 sockets API extensions that might be desired to get TCP MTU information out the kernel, but that's not ipsecme's problem :-) The IKE then needs to update the ESP machinery to know what the MTU of the inside of the tunnel appears to be, and it should generate ICMPs if it's bigger. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] PLMTUD probes for IPsec
Shibu writes: > With SDWAN use cases (wherein paths could be orchestrated based on proto, > port, QoS, App ID etc), would it be a precise assumption to make? How would > we handle these cases when the paths are build for ESP and IKE differently? If the ESP and IKEv2 packates do not follow the same path, then it is possible that the ESP path is broken, and when we run the test over IKEv2 path to see whether connection is broken or not, we do get result that it works, even when ESP does not. Because of this I would say that every SDWAN implementation should try to make sure that all ESP and IKEv2 packets do use the same path as otherwise there might be black holes, or repeated tearing down SAs and recreating them (i.e., if ESP works but IKEv2 does not). In case someone still makes implementation which does that, then IKEv2 can use UDP encapsulation and then both IKEv2 and ESP packets do follow same path. I.e., try to avoid those, or if you make them, make sure they have same PMTU, and if you cannot ensure that, enable UDP encapsulation in IPsec... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] PLMTUD probes for IPsec
Hello Tero and all, We discussed internally among the authors and it looks there exist 3 choices - to do PMTUD over IKE, or ESP or both. (Many reviewers have already pointed out these at various stages, just collating them here). PMTUD over IKE is needed anyways for large IKE cert payloads, so if we do PMTUD over IKE, we could depend upon the same discovered MTU value for ESP paths as well as a guidance value. This seems to work for most of the cases, and there seems to be interest in the group towards this option. So this looks to be a good option overall, if we tackle IKEv2 window nuances effectively. However, one caveat with above approach is that there is an implicit assumption that paths for control and data traffic are same (i.e. IP based, 3 tupple paths). With SDWAN use cases (wherein paths could be orchestrated based on proto, port, QoS, App ID etc), would it be a precise assumption to make? How would we handle these cases when the paths are build for ESP and IKE differently? Thanks, Shibu. On Fri, Apr 13, 2018 at 1:48 PM, Tero Kivinen wrote: > Ron Bonica writes: > > In 99.9% of cases you are probably correct. If there is an ECMP > > between the encrypting node and the decrypting node, all ECMPs have > > the same PMTU. > > Is it 99.9%, or 99.%? > > > And because this is true in such a vast majority of cases, none of > > us have seen a situation where one ECMP has a larger PMTU than then > > next. > > If none has not yet been seen it is much closer to 100% than 99.9%. > Depending of course how many setups people have seen... > > > However, we still need to be prepared for that rare situation where > > one ECMP does have a greater PMTU that the next. Although black > > swans are rare, they bite very hard! > > There is also option to say that network is so broken that we fall > back to IPsec over TCP, and in that case both ESP and IKE packets go > inside same TCP stream and MTU discovery is done simlarly for both, so > things work. I.e., that might be acceptable solution for those rare > really broken cases. > -- > 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] PLMTUD probes for IPsec
On Fri, 13 Apr 2018, Tero Kivinen wrote: Paul Wouters writes: Using IKE also has a disandvantage for for those implementations that only support a window size of one. If those IKE messages are lost - which is highly likely because we are trying out larger window sizes until we find something that works - things get tricky (even trickier then the current liveness + mobike situation) That is good reason for requiring bigger window size if we do this in IKE for implementations supporting this. Actually if you do mobike, you most likely also want to use bigger window sizes... Perhaps such a requirement could help. I still feel the whole msgid handling in IKEv2 requires some clarification document, or perhaps even a change in the specification. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] PLMTUD probes for IPsec
Paul Wouters writes: > Using IKE also has a disandvantage for for those implementations that > only support a window size of one. If those IKE messages are lost - > which is highly likely because we are trying out larger window sizes > until we find something that works - things get tricky (even trickier > then the current liveness + mobike situation) That is good reason for requiring bigger window size if we do this in IKE for implementations supporting this. Actually if you do mobike, you most likely also want to use bigger window sizes... And of course the protocol needs to be designed to work with IKE packets. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] PLMTUD probes for IPsec
Ron Bonica writes: > In 99.9% of cases you are probably correct. If there is an ECMP > between the encrypting node and the decrypting node, all ECMPs have > the same PMTU. Is it 99.9%, or 99.%? > And because this is true in such a vast majority of cases, none of > us have seen a situation where one ECMP has a larger PMTU than then > next. If none has not yet been seen it is much closer to 100% than 99.9%. Depending of course how many setups people have seen... > However, we still need to be prepared for that rare situation where > one ECMP does have a greater PMTU that the next. Although black > swans are rare, they bite very hard! There is also option to say that network is so broken that we fall back to IPsec over TCP, and in that case both ESP and IKE packets go inside same TCP stream and MTU discovery is done simlarly for both, so things work. I.e., that might be acceptable solution for those rare really broken cases. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] PLMTUD probes for IPsec
Ron Bonica writes: > Hi Valery, > > I am thinking like this... > > - If we do nothing, tunnel performance is acceptable but > suboptimal. We can prevent blackholing by statically configuring > the tunnel MTU to a sufficiently low value. However, we cannot > take advantage of tunnels with larger PMTUs. > > - If we use IKE to exchange probes and acks, tunnel performance may > become totally unacceptable. In the situation where a) IKE > messages traverse a different path than encrypted payloads and b) > the PMTU associated with the IKE path is greater than the PMTU > associated with encrypted payload path, we may produce an inflated > estimate of the Tunnel MTU. This may lead to black holing. And same happens, if the ESP packet path gots broken, but IKE path does not. This will lead to black holing. Or if the IKE path is broken but ESP works, the IKE will tear down the whole IKE SA (along with all Child SAs) and start over. Also as we are running TCP or similar inside the IPsec tunnel, that will most likely also notice that packets do not go through with that big MTU and will make packets smaller, or does something here disable end to end PMTUD... > So, our probe and acks have to be exchanged over the IPSEC tunnel. > At first I thought that the best way to do this was by exchanging > UDP messages. But you have a point. If we exchanged encrypted ICMP > Echo / Echo Response messages instead of UDP messages, there would > be slightly less code to write. Furthermore, we wouldn't need to > allocate a new UDP port. I am not really convinced about that yet. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] PLMTUD probes for IPsec
On Wed, 11 Apr 2018, Ron Bonica wrote: - If we do nothing, tunnel performance is acceptable but suboptimal. We can prevent blackholing by statically configuring the tunnel MTU to a sufficiently low value. However, we cannot take advantage of tunnels with larger PMTUs. - If we use IKE to exchange probes and acks, tunnel performance may become totally unacceptable. In the situation where a) IKE messages traverse a different path than encrypted payloads and b) the PMTU associated with the IKE path is greater than the PMTU associated with encrypted payload path, we may produce an inflated estimate of the Tunnel MTU. This may lead to black holing. Using IKE also has a disandvantage for for those implementations that only support a window size of one. If those IKE messages are lost - which is highly likely because we are trying out larger window sizes until we find something that works - things get tricky (even trickier then the current liveness + mobike situation) Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] PLMTUD probes for IPsec
Hi Ron, > I am thinking like this... > > - If we do nothing, tunnel performance is acceptable but suboptimal. We can > prevent blackholing by statically > configuring the tunnel MTU to a sufficiently low value. However, we cannot > take advantage of tunnels with > larger PMTUs. > > - If we use IKE to exchange probes and acks, tunnel performance may become > totally unacceptable. In the > situation where a) IKE messages traverse a different path than encrypted > payloads and b) the PMTU > associated with the IKE path is greater than the PMTU associated with > encrypted payload path, we may > produce an inflated estimate of the Tunnel MTU. This may lead to black holing. Then it is possible to couple PLMTUD with NAT traversal. In other words - send probes over IKE, but only if NAT was detected in between (or NAT traversal is forced by local configuration). In case of NAT traversal all ESP packets will be encapsulated in UDP and sent over the IKE connection (same UDP ports). So in this case we are sure that IKE and ESP paths are the same. > So, our probe and acks have to be exchanged over the IPSEC tunnel. At first I > thought that the best way to do > this was by exchanging UDP messages. But you have a point. If we exchanged > encrypted ICMP Echo / Echo > Response messages instead of UDP messages, there would be slightly less code > to write. Furthermore, we > wouldn't need to allocate a new UDP port. Yes. but if your tunnel allows only TCP (or UDP), then sending ICMP Echo won't work. You still need to be able to send probes over all major transport protocol, otherwise some SPD configurations would prevent this to work. Regards, Valery. > >Ron > > > > -Original Message- > > From: Valery Smyslov > > Sent: Tuesday, April 10, 2018 2:57 AM > > To: Ron Bonica ; 'Michael Richardson' > > > > Cc: ipsec@ietf.org > > Subject: RE: [IPsec] PLMTUD probes for IPsec > > > > Hi Ron, > > > > > Both good points. So, it appears that we have the following choices: > > > > > > - leverage IKE for exchanging probes and acks (But risk sending > > > probes and acks over a different path than encrypted data) > > > - send probes and acks in-band. Try UDP probes first. If that doesn't > > > work, > > try TCP probes. > > > > What about ICMP-only SAs (yeah, it's weird, but possible)? > > > > > Which do you think is better? > > > > Both don't look ideal. I slightly prefer the former, as it looks simpler to > > implement (at least for me), but the issue with different paths can > > outweigh > > all. One potential solution to this issue would be to always use UDP > > encapsulation, but I'm not sure we may impose such a requirement... Your > > opinion? > > > > Regards, > > Valery. > > > > > > > > Ron > > > > > > > > > > -Original Message- > > > > From: Valery Smyslov > > > > Sent: Friday, April 6, 2018 3:24 AM > > > > To: Ron Bonica ; 'Michael Richardson' > > > > > > > > Cc: ipsec@ietf.org > > > > Subject: RE: [IPsec] PLMTUD probes for IPsec > > > > > > > > Hi Ron, > > > > > > > > > Folks, > > > > > > > > > > In the first version of this draft, we leveraged IKE to exchange > > > > > messages. And provided with a good enough reason, we might go back > > > > > to > > > > that position! > > > > > > > > > > We moved away from IKE for the following reasons: > > > > > > > > > > - The path between the encrypting and decrypting nodes might > > > > > include ECMP. If so, IKE messages might take a different path than > > > > > actual encrypted data > > > > > > > > That's a valid concern. The only time when you can be sure that the > > > > paths are the same is when NAT traversal is in use (either because > > > > some NAT is in between, or you force it on the peers). > > > > > > > > > - The current method provides the same level of protection as IKE > > > > > and possibly better performance > > > > > - The current doesn't require changes to IKE > > > > > > > > True. But with your current proposal some changes to the IPSec in > > > > kernel are needed too (or you need to have standalone client an
Re: [IPsec] PLMTUD probes for IPsec
Hi Tero, In 99.9% of cases you are probably correct. If there is an ECMP between the encrypting node and the decrypting node, all ECMPs have the same PMTU. And because this is true in such a vast majority of cases, none of us have seen a situation where one ECMP has a larger PMTU than then next. However, we still need to be prepared for that rare situation where one ECMP does have a greater PMTU that the next. Although black swans are rare, they bite very hard! Ron > -Original Message- > From: Tero Kivinen > Sent: Tuesday, April 10, 2018 6:52 AM > To: Valery Smyslov > Cc: Ron Bonica ; 'Michael Richardson' > ; ipsec@ietf.org > Subject: Re: [IPsec] PLMTUD probes for IPsec > > Valery Smyslov writes: > > > Both good points. So, it appears that we have the following choices: > > > > > > - leverage IKE for exchanging probes and acks (But risk sending > > > probes and acks over a different path than encrypted data) > > > - send probes and acks in-band. Try UDP probes first. If that doesn't > work, try TCP probes. > > > > What about ICMP-only SAs (yeah, it's weird, but possible)? > > > > > Which do you think is better? > > > > Both don't look ideal. I slightly prefer the former, as it looks > > simpler to implement (at least for me), but the issue with different > > paths can outweigh all. One potential solution to this issue would be > > to always use UDP encapsulation, but I'm not sure we may impose such a > > requirement... Your opinion? > > I would just use IKE packets, and ignore the cases where ESP and IKE get > different routes which have different MTUs. I would expect that in most > cases if there is something in the middle using different MTUs then the > routes are not equal cost anymore, thus routing will use only one of the > routes. Usually the issues with MTU comes with road warriors connecting > from random locations around the world, and in most of the cases there will > be NAT for IPv4 in the middle, which will move all traffic to UDP anyways. > > Do we have any real world examples where the ESP and IKE packets > consistently take different routes, and those different routes have different > MTUs? And does all ESP traffic follow always one route, and all IKE traffic > follow another route, or is it more random or based on the SPI or something? > > I do not know enough to really say whether such cases exists or do not > exists, but before we start to make complicated protocols to cope with cases > which are very rare, I want to get more information. > > If those cases are very rare, I might still want to make sure IPsec works > somehow, even if it is not as efficient as it could be (i.e., there might be > extra > fragmentation happening or finding proper MTU might take more time). > -- > kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] PLMTUD probes for IPsec
Hi Valery, I am thinking like this... - If we do nothing, tunnel performance is acceptable but suboptimal. We can prevent blackholing by statically configuring the tunnel MTU to a sufficiently low value. However, we cannot take advantage of tunnels with larger PMTUs. - If we use IKE to exchange probes and acks, tunnel performance may become totally unacceptable. In the situation where a) IKE messages traverse a different path than encrypted payloads and b) the PMTU associated with the IKE path is greater than the PMTU associated with encrypted payload path, we may produce an inflated estimate of the Tunnel MTU. This may lead to black holing. So, our probe and acks have to be exchanged over the IPSEC tunnel. At first I thought that the best way to do this was by exchanging UDP messages. But you have a point. If we exchanged encrypted ICMP Echo / Echo Response messages instead of UDP messages, there would be slightly less code to write. Furthermore, we wouldn't need to allocate a new UDP port. Ron > -Original Message- > From: Valery Smyslov > Sent: Tuesday, April 10, 2018 2:57 AM > To: Ron Bonica ; 'Michael Richardson' > > Cc: ipsec@ietf.org > Subject: RE: [IPsec] PLMTUD probes for IPsec > > Hi Ron, > > > Both good points. So, it appears that we have the following choices: > > > > - leverage IKE for exchanging probes and acks (But risk sending > > probes and acks over a different path than encrypted data) > > - send probes and acks in-band. Try UDP probes first. If that doesn't work, > try TCP probes. > > What about ICMP-only SAs (yeah, it's weird, but possible)? > > > Which do you think is better? > > Both don't look ideal. I slightly prefer the former, as it looks simpler to > implement (at least for me), but the issue with different paths can outweigh > all. One potential solution to this issue would be to always use UDP > encapsulation, but I'm not sure we may impose such a requirement... Your > opinion? > > Regards, > Valery. > > > > > Ron > > > > > > > -Original Message----- > > > From: Valery Smyslov > > > Sent: Friday, April 6, 2018 3:24 AM > > > To: Ron Bonica ; 'Michael Richardson' > > > > > > Cc: ipsec@ietf.org > > > Subject: RE: [IPsec] PLMTUD probes for IPsec > > > > > > Hi Ron, > > > > > > > Folks, > > > > > > > > In the first version of this draft, we leveraged IKE to exchange > > > > messages. And provided with a good enough reason, we might go back > > > > to > > > that position! > > > > > > > > We moved away from IKE for the following reasons: > > > > > > > > - The path between the encrypting and decrypting nodes might > > > > include ECMP. If so, IKE messages might take a different path than > > > > actual encrypted data > > > > > > That's a valid concern. The only time when you can be sure that the > > > paths are the same is when NAT traversal is in use (either because > > > some NAT is in between, or you force it on the peers). > > > > > > > - The current method provides the same level of protection as IKE > > > > and possibly better performance > > > > - The current doesn't require changes to IKE > > > > > > True. But with your current proposal some changes to the IPSec in > > > kernel are needed too (or you need to have standalone client and > > > server applications to exchange probes). > > > Not sure what is easier. > > > > > > > Are these reasonable assumptions. If not, we would be happy to > > > > return to > > > the IKE solution. > > > > > > I think one problem with the suggested approach is that the tunnel > > > selectors might not allow sending packets over UDP. Consider you > > > have "narrow" ESP SA that only allows TCP packets to go through and > > > drops all UDP. In this case your approach won't work, or some additional > heuristics would be needed. > > > > > > Regards, > > > Valery. > > > > > > >Ron > > > > > > > > > > > > > -Original Message- > > > > > From: Michael Richardson > > > > > Sent: Thursday, April 5, 2018 11:09 AM > > > > > To: Valery Smyslov > > > > > Cc: ips
Re: [IPsec] PLMTUD probes for IPsec
Valery Smyslov writes: > > Both good points. So, it appears that we have the following choices: > > > > - leverage IKE for exchanging probes and acks (But risk sending probes and > > acks over a different path than > > encrypted data) > > - send probes and acks in-band. Try UDP probes first. If that doesn't work, > > try TCP probes. > > What about ICMP-only SAs (yeah, it's weird, but possible)? > > > Which do you think is better? > > Both don't look ideal. I slightly prefer the former, as it looks > simpler to implement (at least for me), but the issue with different > paths can outweigh all. One potential solution to this issue would > be to always use UDP encapsulation, but I'm not sure we may impose > such a requirement... Your opinion? I would just use IKE packets, and ignore the cases where ESP and IKE get different routes which have different MTUs. I would expect that in most cases if there is something in the middle using different MTUs then the routes are not equal cost anymore, thus routing will use only one of the routes. Usually the issues with MTU comes with road warriors connecting from random locations around the world, and in most of the cases there will be NAT for IPv4 in the middle, which will move all traffic to UDP anyways. Do we have any real world examples where the ESP and IKE packets consistently take different routes, and those different routes have different MTUs? And does all ESP traffic follow always one route, and all IKE traffic follow another route, or is it more random or based on the SPI or something? I do not know enough to really say whether such cases exists or do not exists, but before we start to make complicated protocols to cope with cases which are very rare, I want to get more information. If those cases are very rare, I might still want to make sure IPsec works somehow, even if it is not as efficient as it could be (i.e., there might be extra fragmentation happening or finding proper MTU might take more time). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] PLMTUD probes for IPsec
Hi Ron, > Both good points. So, it appears that we have the following choices: > > - leverage IKE for exchanging probes and acks (But risk sending probes and > acks over a different path than > encrypted data) > - send probes and acks in-band. Try UDP probes first. If that doesn't work, > try TCP probes. What about ICMP-only SAs (yeah, it's weird, but possible)? > Which do you think is better? Both don't look ideal. I slightly prefer the former, as it looks simpler to implement (at least for me), but the issue with different paths can outweigh all. One potential solution to this issue would be to always use UDP encapsulation, but I'm not sure we may impose such a requirement... Your opinion? Regards, Valery. >Ron > > > > -Original Message- > > From: Valery Smyslov > > Sent: Friday, April 6, 2018 3:24 AM > > To: Ron Bonica ; 'Michael Richardson' > > > > Cc: ipsec@ietf.org > > Subject: RE: [IPsec] PLMTUD probes for IPsec > > > > Hi Ron, > > > > > Folks, > > > > > > In the first version of this draft, we leveraged IKE to exchange > > > messages. And provided with a good enough reason, we might go back to > > that position! > > > > > > We moved away from IKE for the following reasons: > > > > > > - The path between the encrypting and decrypting nodes might include > > > ECMP. If so, IKE messages might take a different path than actual > > > encrypted data > > > > That's a valid concern. The only time when you can be sure that the paths > > are > > the same is when NAT traversal is in use (either because some NAT is in > > between, or you force it on the peers). > > > > > - The current method provides the same level of protection as IKE and > > > possibly better performance > > > - The current doesn't require changes to IKE > > > > True. But with your current proposal some changes to the IPSec in kernel are > > needed too (or you need to have standalone client and server applications to > > exchange probes). > > Not sure what is easier. > > > > > Are these reasonable assumptions. If not, we would be happy to return to > > the IKE solution. > > > > I think one problem with the suggested approach is that the tunnel selectors > > might not allow sending packets over UDP. Consider you have "narrow" ESP > > SA that only allows TCP packets to go through and drops all UDP. In this > > case > > your approach won't work, or some additional heuristics would be needed. > > > > Regards, > > Valery. > > > > >Ron > > > > > > > > > > -Original Message- > > > > From: Michael Richardson > > > > Sent: Thursday, April 5, 2018 11:09 AM > > > > To: Valery Smyslov > > > > Cc: ipsec@ietf.org; Ron Bonica > > > > Subject: Re: [IPsec] PLMTUD probes for IPsec > > > > > > > > > > > > Valery Smyslov wrote: > > > > >> > Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica > > > > >> > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.iet > > > > f.org_meeting_101_materials_slides-2D101- > > 2D&d=DwICAg&c=HAkYuh63rsuhr > > > > 6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl- > > AWF2EfpHcA > > > > > > wrDThKP8&m=QoSMQregi2cS6qaSUZ1ttnd_izUvFwYYoIA80K3xgI8&s=YXPwE > > w5OTeG > > > > sOP8sS0P463jWQ-OhKpYEK9LUnAWcQgA&e= > > > > ipsecme-packetization-layer-path-mtu- > > > > >> discovery-01 > > > > >> > > > > >> > Problem: IPsec Tunnel has an PMTU as any other tunnel. > > > > >> > Solution in Transport Area: Inband Path discovery > > > > >> > > > > >> I spoke to Ron afterwards, and I'm very enthusiatic about > > > > getting PLPMTUD > > > > >> widely deployed. We didn't get to this slides, so we didn't > > > > figure > > > > >> out what he needs. Slides talk about an IP-level probe that IPsec > > > > >> encapsulators can use to get estimate for tunnel inner MTU. > > > > > > > > > Why IKE messages cannot be used for this purpose? > > > > > > >
Re: [IPsec] PLMTUD probes for IPsec
Valery, Both good points. So, it appears that we have the following choices: - leverage IKE for exchanging probes and acks (But risk sending probes and acks over a different path than encrypted data) - send probes and acks in-band. Try UDP probes first. If that doesn't work, try TCP probes. Which do you think is better? Ron > -Original Message- > From: Valery Smyslov > Sent: Friday, April 6, 2018 3:24 AM > To: Ron Bonica ; 'Michael Richardson' > > Cc: ipsec@ietf.org > Subject: RE: [IPsec] PLMTUD probes for IPsec > > Hi Ron, > > > Folks, > > > > In the first version of this draft, we leveraged IKE to exchange > > messages. And provided with a good enough reason, we might go back to > that position! > > > > We moved away from IKE for the following reasons: > > > > - The path between the encrypting and decrypting nodes might include > > ECMP. If so, IKE messages might take a different path than actual > > encrypted data > > That's a valid concern. The only time when you can be sure that the paths are > the same is when NAT traversal is in use (either because some NAT is in > between, or you force it on the peers). > > > - The current method provides the same level of protection as IKE and > > possibly better performance > > - The current doesn't require changes to IKE > > True. But with your current proposal some changes to the IPSec in kernel are > needed too (or you need to have standalone client and server applications to > exchange probes). > Not sure what is easier. > > > Are these reasonable assumptions. If not, we would be happy to return to > the IKE solution. > > I think one problem with the suggested approach is that the tunnel selectors > might not allow sending packets over UDP. Consider you have "narrow" ESP > SA that only allows TCP packets to go through and drops all UDP. In this case > your approach won't work, or some additional heuristics would be needed. > > Regards, > Valery. > > > Ron > > > > > > > -Original Message- > > > From: Michael Richardson > > > Sent: Thursday, April 5, 2018 11:09 AM > > > To: Valery Smyslov > > > Cc: ipsec@ietf.org; Ron Bonica > > > Subject: Re: [IPsec] PLMTUD probes for IPsec > > > > > > > > > Valery Smyslov wrote: > > > >> > Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica > > > >> > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.iet > > > f.org_meeting_101_materials_slides-2D101- > 2D&d=DwICAg&c=HAkYuh63rsuhr > > > 6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl- > AWF2EfpHcA > > > > wrDThKP8&m=QoSMQregi2cS6qaSUZ1ttnd_izUvFwYYoIA80K3xgI8&s=YXPwE > w5OTeG > > > sOP8sS0P463jWQ-OhKpYEK9LUnAWcQgA&e= > > > ipsecme-packetization-layer-path-mtu- > > > >> discovery-01 > > > >> > > > >> > Problem: IPsec Tunnel has an PMTU as any other tunnel. > > > >> > Solution in Transport Area: Inband Path discovery > > > >> > > > >> I spoke to Ron afterwards, and I'm very enthusiatic about > > > getting PLPMTUD > > > >> widely deployed. We didn't get to this slides, so we didn't figure > > > >> out what he needs. Slides talk about an IP-level probe that IPsec > > > >> encapsulators can use to get estimate for tunnel inner MTU. > > > > > > > Why IKE messages cannot be used for this purpose? > > > > > > I think that possibly it can, and this is the kind of discussion that > > > I think we should have. The advantage of doing that is that it requires > > > no new code on the responder! That's a big win for deploying. > > > It means that this can be done unilaterally, no new specification, > > > just implementation advice. > > > > > > The slight implementation challenge is making sure that the IKE > > > traffic is going along the same path as the ESP traffic. I'd like > > > to hear from Ron about whether this is an issue. > > > > > > I also thought about using having some plpmtud on each end make a > > > TCP connection *within* the tunnel and use the already defined plpmtu > for TCP. > > > That might be really easy for systems without user/kernel division
Re: [IPsec] PLMTUD probes for IPsec
Hi Ron, > Folks, > > In the first version of this draft, we leveraged IKE to exchange messages. > And provided with a good enough > reason, we might go back to that position! > > We moved away from IKE for the following reasons: > > - The path between the encrypting and decrypting nodes might include ECMP. If > so, IKE messages might take a > different path than actual encrypted data That's a valid concern. The only time when you can be sure that the paths are the same is when NAT traversal is in use (either because some NAT is in between, or you force it on the peers). > - The current method provides the same level of protection as IKE and > possibly better performance > - The current doesn't require changes to IKE True. But with your current proposal some changes to the IPSec in kernel are needed too (or you need to have standalone client and server applications to exchange probes). Not sure what is easier. > Are these reasonable assumptions. If not, we would be happy to return to the > IKE solution. I think one problem with the suggested approach is that the tunnel selectors might not allow sending packets over UDP. Consider you have "narrow" ESP SA that only allows TCP packets to go through and drops all UDP. In this case your approach won't work, or some additional heuristics would be needed. Regards, Valery. >Ron > > > > -Original Message- > > From: Michael Richardson > > Sent: Thursday, April 5, 2018 11:09 AM > > To: Valery Smyslov > > Cc: ipsec@ietf.org; Ron Bonica > > Subject: Re: [IPsec] PLMTUD probes for IPsec > > > > > > Valery Smyslov wrote: > > >> > Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica > > >> > https://datatracker.ietf.org/meeting/101/materials/slides-101- > > ipsecme-packetization-layer-path-mtu- > > >> discovery-01 > > >> > > >> > Problem: IPsec Tunnel has an PMTU as any other tunnel. > > >> > Solution in Transport Area: Inband Path discovery > > >> > > >> I spoke to Ron afterwards, and I'm very enthusiatic about getting > > PLPMTUD > > >> widely deployed. We didn't get to this slides, so we didn't figure > > >> out what he needs. Slides talk about an IP-level probe that IPsec > > >> encapsulators can use to get estimate for tunnel inner MTU. > > > > > Why IKE messages cannot be used for this purpose? > > > > I think that possibly it can, and this is the kind of discussion that > > I think we should have. The advantage of doing that is that it requires > > no new code on the responder! That's a big win for deploying. > > It means that this can be done unilaterally, no new specification, just > > implementation advice. > > > > The slight implementation challenge is making sure that the IKE traffic is > > going > > along the same path as the ESP traffic. I'd like to hear from Ron about > > whether this is an issue. > > > > I also thought about using having some plpmtud on each end make a TCP > > connection *within* the tunnel and use the already defined plpmtu for TCP. > > That might be really easy for systems without user/kernel divisions (some > > router kernels). It would require some notifications to indicate that the > > responder has a TCP port open. And of course, the traffic would have to fit > > into the tunnel as well. > > > > > > > > > > > Regards, > > > Valery. > > > > >> But, if we can get PLMTUD deployed for all traffic, then the > > end-nodes > > can > > >> do appropriate PMTU probing and can figure out what the inner MTU is. > > >> i.e. just get everyone to enable plpmtu (4821). It's a knob on most > > >> systems, which has been left in the off state because of lack of > > evidence > > >> that it isn't harmful. > > >> > > >> There seems to be some sticking points among the high-speed about > > CDNs: > > >> they hate all PMTUD as it screws with tx scheduling into hardware. > > >> (TCP segment offload issues) > > >> > > >> So they just use 1280 is what I was told. That's good for the > > network, > > but > > >> it removes them as strong allies for getting PLPMTUD enabled by > > default > > >> everywhere. It would be nice if we could get a BCP out of them. > > Such > > >> BCP could also bless PLPMTUD for everyone else. I was pushing for > > this > > >> with RFC8200/STD86 but there was insufficient evidence of > > deployment. > > >> > > >> -- > > >> Michael Richardson , Sandelman Software > > Works > > >> -= IPv6 IoT consulting =- > > >> > > >> > > > > > > > > -- > > Michael Richardson , Sandelman Software Works > > -= IPv6 IoT consulting =- > > > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] PLMTUD probes for IPsec
Folks, In the first version of this draft, we leveraged IKE to exchange messages. And provided with a good enough reason, we might go back to that position! We moved away from IKE for the following reasons: - The path between the encrypting and decrypting nodes might include ECMP. If so, IKE messages might take a different path than actual encrypted data - The current method provides the same level of protection as IKE and possibly better performance - The current doesn't require changes to IKE Are these reasonable assumptions. If not, we would be happy to return to the IKE solution. Ron > -Original Message- > From: Michael Richardson > Sent: Thursday, April 5, 2018 11:09 AM > To: Valery Smyslov > Cc: ipsec@ietf.org; Ron Bonica > Subject: Re: [IPsec] PLMTUD probes for IPsec > > > Valery Smyslov wrote: > >> > Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica > >> > https://datatracker.ietf.org/meeting/101/materials/slides-101- > ipsecme-packetization-layer-path-mtu- > >> discovery-01 > >> > >> > Problem: IPsec Tunnel has an PMTU as any other tunnel. > >> > Solution in Transport Area: Inband Path discovery > >> > >> I spoke to Ron afterwards, and I'm very enthusiatic about getting > PLPMTUD > >> widely deployed. We didn't get to this slides, so we didn't figure > >> out what he needs. Slides talk about an IP-level probe that IPsec > >> encapsulators can use to get estimate for tunnel inner MTU. > > > Why IKE messages cannot be used for this purpose? > > I think that possibly it can, and this is the kind of discussion that > I think we should have. The advantage of doing that is that it requires > no new code on the responder! That's a big win for deploying. > It means that this can be done unilaterally, no new specification, just > implementation advice. > > The slight implementation challenge is making sure that the IKE traffic is > going > along the same path as the ESP traffic. I'd like to hear from Ron about > whether this is an issue. > > I also thought about using having some plpmtud on each end make a TCP > connection *within* the tunnel and use the already defined plpmtu for TCP. > That might be really easy for systems without user/kernel divisions (some > router kernels). It would require some notifications to indicate that the > responder has a TCP port open. And of course, the traffic would have to fit > into the tunnel as well. > > > > > > Regards, > > Valery. > > >> But, if we can get PLMTUD deployed for all traffic, then the end-nodes > can > >> do appropriate PMTU probing and can figure out what the inner MTU is. > >> i.e. just get everyone to enable plpmtu (4821). It's a knob on most > >> systems, which has been left in the off state because of lack of > evidence > >> that it isn't harmful. > >> > >> There seems to be some sticking points among the high-speed about > CDNs: > >> they hate all PMTUD as it screws with tx scheduling into hardware. > >> (TCP segment offload issues) > >> > >> So they just use 1280 is what I was told. That's good for the network, > but > >> it removes them as strong allies for getting PLPMTUD enabled by > default > >> everywhere. It would be nice if we could get a BCP out of them. Such > >> BCP could also bless PLPMTUD for everyone else. I was pushing for this > >> with RFC8200/STD86 but there was insufficient evidence of > deployment. > >> > >> -- > >> Michael Richardson , Sandelman Software > Works > >> -= IPv6 IoT consulting =- > >> > >> > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] PLMTUD probes for IPsec
Valery Smyslov wrote: >> > Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica >> > https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-packetization-layer-path-mtu- >> discovery-01 >> >> > Problem: IPsec Tunnel has an PMTU as any other tunnel. >> > Solution in Transport Area: Inband Path discovery >> >> I spoke to Ron afterwards, and I'm very enthusiatic about getting PLPMTUD >> widely deployed. We didn't get to this slides, so we didn't figure >> out what he needs. Slides talk about an IP-level probe that IPsec >> encapsulators can use to get estimate for tunnel inner MTU. > Why IKE messages cannot be used for this purpose? I think that possibly it can, and this is the kind of discussion that I think we should have. The advantage of doing that is that it requires no new code on the responder! That's a big win for deploying. It means that this can be done unilaterally, no new specification, just implementation advice. The slight implementation challenge is making sure that the IKE traffic is going along the same path as the ESP traffic. I'd like to hear from Ron about whether this is an issue. I also thought about using having some plpmtud on each end make a TCP connection *within* the tunnel and use the already defined plpmtu for TCP. That might be really easy for systems without user/kernel divisions (some router kernels). It would require some notifications to indicate that the responder has a TCP port open. And of course, the traffic would have to fit into the tunnel as well. > Regards, > Valery. >> But, if we can get PLMTUD deployed for all traffic, then the end-nodes can >> do appropriate PMTU probing and can figure out what the inner MTU is. >> i.e. just get everyone to enable plpmtu (4821). It's a knob on most >> systems, which has been left in the off state because of lack of evidence >> that it isn't harmful. >> >> There seems to be some sticking points among the high-speed about CDNs: >> they hate all PMTUD as it screws with tx scheduling into hardware. >> (TCP segment offload issues) >> >> So they just use 1280 is what I was told. That's good for the network, but >> it removes them as strong allies for getting PLPMTUD enabled by default >> everywhere. It would be nice if we could get a BCP out of them. Such >> BCP could also bless PLPMTUD for everyone else. I was pushing for this >> with RFC8200/STD86 but there was insufficient evidence of deployment. >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> -- 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] PLMTUD probes for IPsec
Hi Paul, > > Why IKE messages cannot be used for this purpose? > > IKE messages might not take the same path, eg ESP goes through hardware > offload or other things, or intermediary routers might have different > rules for UDP vs ESP. True, unless UDP encapsulation is used... Regards, Valery. > Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] PLMTUD probes for IPsec
On Thu, 5 Apr 2018, Valery Smyslov wrote: Why IKE messages cannot be used for this purpose? IKE messages might not take the same path, eg ESP goes through hardware offload or other things, or intermediary routers might have different rules for UDP vs ESP. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] PLMTUD probes for IPsec
Hi Michael, > > Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica > > > https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-packetization-layer-path-mtu- > discovery-01 > > > Problem: IPsec Tunnel has an PMTU as any other tunnel. > > Solution in Transport Area: Inband Path discovery > > I spoke to Ron afterwards, and I'm very enthusiatic about getting PLPMTUD > widely deployed. We didn't get to this slides, so we didn't figure > out what he needs. Slides talk about an IP-level probe that IPsec > encapsulators can use to get estimate for tunnel inner MTU. Why IKE messages cannot be used for this purpose? Regards, Valery. > But, if we can get PLMTUD deployed for all traffic, then the end-nodes can > do appropriate PMTU probing and can figure out what the inner MTU is. > i.e. just get everyone to enable plpmtu (4821). It's a knob on most > systems, which has been left in the off state because of lack of evidence > that it isn't harmful. > > There seems to be some sticking points among the high-speed about CDNs: > they hate all PMTUD as it screws with tx scheduling into hardware. > (TCP segment offload issues) > > So they just use 1280 is what I was told. That's good for the network, but > it removes them as strong allies for getting PLPMTUD enabled by default > everywhere. It would be nice if we could get a BCP out of them. Such > BCP could also bless PLPMTUD for everyone else. I was pushing for this > with RFC8200/STD86 but there was insufficient evidence of deployment. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec