Re: [IPsec] [Lwip] Iotdir last call review of draft-ietf-lwig-minimal-esp-03
Hi Nancy, Regarding ISSUE 3, I have the impression that the concern that AES-GCM, Chacha20-Poly1305 or AES-CCM only send a 64 bit IV which suggest that only 64 bit IV can be sent with ESP. In fact the IV is not a field in ESP but is defined for each suite, as a result, ESP would be able to support any suite with larger or short IV. Then, the use of a 96 bit nonce is not uncommon, actually AES-GCM and Chacha20-Poly1305 do use 96 bit nonce and AES-CCM uses a 88 bit nonce. The nonce is formed based on a slat and the IV. Similar construction may be provided for AES-GCM-SIV if needed as far as I can see. AES-GCM-SIV is only defined as an algorithm, I also suggest to add other alternatives that have a similar goals. The current text is as follows and I think it might close the ISSUE 3. When the key is likely to be re-used across reboots, it is RECOMMENDED to consider algorithms that are nonce misuse resistant such as, for example, AES-SIV [RFC5297], AES-GCM-SIV [RFC8452] or Deoxys-II [deoxys]. Note however that currently none of them has yet been defined for ESP. I suspect the ISSUE 1 and ISSUE 2 are related to IV collision. If so it seems to me related to the collision of IV. If so I think the current proposed text for SN addresses the concerns that an algorithm should not be used beyond its limits. In addition the following text in the security consideration seems to address that concern as well: the nodes MUST ensure that keys are not used beyond their lifetime and that the appropriate use of the key remains across reboots - e.g. conditions on counters and nonces remains valid. I suspect that collision is related to the collision of IV which is only a concern when the IV needs to be unpredictable. I am tempted to think that algorithms that the properties of the IV are really part of the algorithm properties and that they cover / include into the lifetime of the keys. On the other hand, most recommended algorithms AES-GCM, AES-CCM, Chacha-Poly1305 are using IVs that just do not need to repeat, and so use counters where collision is not a concern. Of course this does not concerne collision across reboot, but I do not think these were the collisions that caused your concern. If I am correct, that probably also addresses ISSUEs 1 and ISSUE 2. I will publish the version with the current changes so reviews have the most recent editorial changes and will update from that according to your response. Again thank you for the in depth review and the many comments that already result in many clarifications - at least I think so. Yours, Daniel On Tue, Mar 30, 2021 at 10:45 PM Daniel Migault wrote: > Hi Nancy, > > Thank you very much for your review. Please see inline my responses. I > believe all concerns raised have been addressed. I also believe the current > text addresses some concerns also raised by Paul W. > > The current version can be found here: > > https://github.com/mglt/draft-mglt-lwig-minimal-esp/pull/1/commits/fb9393a246298e37adcf2683afa2061a40b4ed89 > > I think there are however three remaining issues that might get further > discussions. For all of these I provided a response, but I am unsure it > really addresses the three concerns below: > > > ISSUE 1 > > - I might challenge due to potential collision attacks that at > most, 2^32-1 packets may be sent before the SPI *must* rekey, so the SN > and how > it is used is part of the security context for the SPI/SA. I might also > challenge that a recommendation for using a rekey mechanism is warranted > because constrained devices tend to stay up for very, very, very long > periods > of time and even with an ESN there can be exhaustion :-) > > I am missing the concern. I understand the first concern is that the > current text seems to push the limit of packets being sent being determined > by the SN as opposed to cryptographic properties. If my understanding is > correct, I have the current text seems clear that crypto properties are > given priorities. I suspect more guidance would be given. If that is the > case, I find it difficult as these guidances are really based on the > cryptographic algorithm and the key sizes. In any case, if I am > missing something, feel free to propose some text. > > """ > Note that the limit of messages being sent is primarily determined by the > security associated with the key rather than the SN. > The security of all data protected under a given key decreases slightly > with each message and a node MUST ensure the limit is not reached - even > though the SN would permit it. > """ > > I understand the second concern as that current text is read as rekey > mechanisms are recommended only when there is a risk the SN get exhausted. > Our intention was to read the text as even if ESN raises the limit to an > acceptable limit, it is preferred to have a rekey mechanism. I propose the > following text to clarify the meaning: > > OLD: > In a constrained environment, it is likely that the implementation of a >
Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07
Bottorff, Paul writes: > The RFC3948 specifies one pair of UDP ports 4500-4500. No it does not. It says you must use same ports than what you do for IKE traffic. > Both the IKE flow and the ESP in UDP flow should use the same UDP > flow. The draft seems to suggest new destination port and source > ports are only for ESP? How would this change work with IKE? May you > are not intending to use IKE? The reason NAT-T uses same ports for both ESP and IKE is to make sure that responder will know the port mapping from the IKE packets for ESP packets too. If they would use different port numbers, then responder would need to wait for first ESP packet to come in from the initiator before it can send any ESP packets back, as it would be able to know which port numbers to use for ESP traffic. Also keepalives would be needed to do for both IKE and ESP separately. > PB>>Our use cases use IKE, however as stated in RFC3948 ESPinUDP does not > have to be tied to IKE, it is just advantageous to do so for the NAT case > since this allows a single mapping for both at the NAT rather than two > mappings. > PB>>I've wondered why we could not use the RFC3948 encoding for ESPinUDP, but > allow the source port to be chosen differently than IKE. Perhaps Xu has some > thoughts on this. > << As there is no way for the responder to know whether the initiator sent the packet out using source port of 4500 and then NAT changed it to port number of , or whether the initiator sent the packet out using port number of himself, the RFC7296 do require that responder MUST accept incoming packets regardless of the source port, and MUST always respond back to exactly same IP and port than what was in the source packet of the request: >From the 2.11 of the RFC7296: An implementation MUST accept incoming requests even if the source port is not 500 or 4500, and MUST respond to the address and port from which the request was received. It MUST specify the address and port at which the request was received as the source address and port in the response. There is text in 2.23 of the RFC7296 which do say: For this reason, even though IKE packets MUST be sent to and from UDP port 500 or 4500, they MUST be accepted coming from any port and responses MUST be sent to the port from whence they came. Which is bit funny, as the "even though" claims that IKE packets must be sent to and from UDP port 500 or 4500, and there is no such claim anywhere else in the RFC7296. I think it was supposed to say that "even though IKE packets are normally sent ...", as this is not correct place to make this kind of new requirement. So making IKE implementation which uses some other source port than 500 or 4500 is common way to force NAT-T traversal and UDP encapsulation on, and in that way allow user mode IKE + IPsec to be implemented without affecting the in kernel version of the IPsec in the host. I.e., user mode application wanting to use IPsec in usermode without affecting host IPsec in any ways can use any random port as source port and port 4500 as the destination port, and make sure that NAT_DETECTION_SOURCE_IP does not match, so responder will enable udp encapsulation. The responder MUST work even with that setup, so there is no reason why there should be requirement for the oritinal sender should be mandated to use source port 4500... > PB>>We are mostly interested in data centre use cases which don't have > intervening NATs, however I believe SD-WAN cases could have NAT and FW > traversals between tunnel end points. As it stands > draft-xu-ipsecme-esp-in-udp-lb does not specify how the source port value is > determined. It seems like it could be based on a hash value within the ESP or > based on the SPI and IPs. > << > > Should both sides use the same source port? For the load balancing I think it is enough for just one of the ports to be different, thus initiator could simply allocate n random source port numbers, and initiate IKE from each of them to responder, and then create SAs for each of them separately, thus allowing load balancing using UDP encapsulation using existing hardware. The real issue is that if you do not want to create n separate IKE SAs, then you need to do something special, and there are other things that needs to be considered then. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07
On Thu, 1 Apr 2021, Antony Antony wrote: In my experience it would work well when there is no NAT. When there there is NAT the IKE and ESP in UDP should use same ports, otherwise IKE will get established and ESP packets could get dropped in one direction. When there is NAT it would look more like a client-to-server than a peer-to-peer. One idea could be to use MOBIKE probes (without UPDATE_SA) by the initiator behind NAT to get multiple NAT mappings? It might require kernel changes depending on how it implements NAT updates :/ I implemented a proof concept - UDP source port set to 16bit hash of out going SPI. Then it occurred to me the hash could collide with other well known UDP ports e.g. hash of an SPI or/and IP address could be 53(DNS). Some admins may not be happy to see source port 53 for ESP in UDP traffic. I seen this in the wild already with a large VPN provider blocking port 19 (chargen) and NAT gateways picking port 19 as source port. While this could be an attack to try and trigger chargen responses from a spoofed packet, I don't think it is. It might work for TCP, but not really for UDP as a DoS attack. I think in the end, sadly, we have to expect every port to be used by badly designed NAT gateways. However, it would still be a good design to keep UDP source ports in the ephemeral ranges. This also helps against local policy enforcements, such as Linux's SElinux policies. If you choose ephemeral source ports both sides should know the source ports otherwise SADB remap will be generated. If we disable that real NAT would break... So far I don't have a clean solution which would work with NAT and without NAT for our use case. That is indeed the real problem to solve. I have to do some more testingwith MOBIKE probes on the same IP with only port differences and see if the kernel acts like these are port updates or not if it is only IKEinUDP and not ESPinUDP. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07
On Wed, Mar 31, 2021 at 23:38:01 +, Bottorff, Paul wrote: > Hi Antony: > > Below, > > Cheers, > > Paul > > > > -Original Message- > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Antony Antony > Sent: Wednesday, March 31, 2021 3:32 AM > To: Bottorff, Paul ; IPsec > Cc: antony.ant...@secunet.com > Subject: Re: [IPsec] draft-xu-ipsecme-esp-in-udp-lb-07 > > Hi, > > This is an interesting draft. I would love to see a generic solution for > network paths and receiver use cases, such as RSS. > > PB>> Can you explain your use case for RSS a little more? I'd guess you are > looking at LB around the RSS queues to get better distribution for the > decodes. > << We are using muliple SAs, with identical Traffic Selectors, to load balance IPsec traffic between IPsec peers. https://datatracker.ietf.org/doc/draft-pwouters-multi-sa-performance/ This should improve multi-core-cpu utilization and IPsec throughput. The receiver should distribute the flows, based on SPI, to different CPUs for decryption. Ideally the NIC should support a ntuple flow distribution using SPI. It is not yet widely supported, and also not compatible with older NICs. Now we are thinking of ESP in UDP with different source ports. Just like the draft proposed for ECMP and LAG. When implementing it I ran into issues with NAT and SAD remapping messages which update IKE. I am using strongSWAN for IKE and Linux XFRM for ESP. > The RFC3948 specifies one pair of UDP ports 4500-4500. > Both the IKE flow and the ESP in UDP flow should use the same UDP flow. > The draft seems to suggest new destination port and source ports are only for > ESP? How would this change work with IKE? > May you are not intending to use IKE? PB> Our use cases use IKE, however as stated in RFC3948 ESPinUDP does not have to be PB> tied to IKE, it is just advantageous to do so for the NAT case since this allows PB> a single mapping for both at the NAT rather than two mappings. PB> I've wondered why we could not use the RFC3948 encoding for ESPinUDP, but allow PB> the source port to be chosen differently than IKE. Perhaps Xu has some thoughts on this. In my experience it would work well when there is no NAT. When there there is NAT the IKE and ESP in UDP should use same ports, otherwise IKE will get established and ESP packets could get dropped in one direction. When there is NAT it would look more like a client-to-server than a peer-to-peer. > How would the new ESP flow work when there is a NAT gateway along the path? > I ran into issues with both sides choosing different source ports. > It would cause SADB mapping changes which force changes IKE flows. One coul > disable > SADB mapping changes. However, that would break real NAT changes. > PB> We are mostly interested in data centre use cases which don't have intervening NATs, PB> however I believe SD-WAN cases could have NAT and FW traversals between tunnel end PB> points. As it stands draft-xu-ipsecme-esp-in-udp-lb does not specify how the source port PB> value is determined. It seems like it could be based on a hash value within the ESP or PB> based on the SPI and IPs. I implemented a proof concept - UDP source port set to 16bit hash of out going SPI. Then it occurred to me the hash could collide with other well known UDP ports e.g. hash of an SPI or/and IP address could be 53(DNS). Some admins may not be happy to see source port 53 for ESP in UDP traffic. If you choose ephemeral source ports both sides should know the source ports otherwise SADB remap will be generated. If we disable that real NAT would break... So far I don't have a clean solution which would work with NAT and without NAT for our use case. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
