Yaron Sheffer writes: > Herbert: > "Implementations MUST process received UDP-encapsulated ESP packets even > when no NAT was detected." > > was added to the draft. This has the potential to create black holes if > deployed in the field, unless all implementations always use UDP > encapsulation regardless of NAT.
I do not think it creates any more black holes than what is generally generated by the broken firewalls in the middle. There is already now black hole generated by IKEv2 implementations doing NAT detection incorrectly, and enabling NAT-T even when no NAT is detected (I have seen such implementation). If you drop all UDP encapsulated ESP packets if no NAT was detected, then this will cause black hole, as you will not receive any of his IPsec packets as you drop them, and he might or might not receive your packets depending whether he requires them to be UDP encapsulated or not. In this implementation I have seen this was not really a problem, as both ends supported MOBIKE, which requires processing both UDP encapsulated and plain IPsec always, thus both ends were able to process packets, but UDP encapsulation was used in one direction but not in other. > The problem is that if a peer behind a firewall (with no NAT) that > only allows inbound packets which are in response to outbound > packets performs UDP encapsulation without NAT, and the remote peer > responds without UDP encapsulation, then all data packets from the > remote peer will be dropped. In normal case this means that the IKE SA will be formed, but no IPsec traffic will go through in either direction. I.e. neither end will enable UDP encapsulation as no NAT is detected, thus both ends will use plain ESP, and those will not go through, so this requirement does not change the situation. Note, that the statemenet added does not say anything that SENDING UDP-encapsulated ESP packets would be required or preferred or even allowed (it is not forbidden either). The text allows easier extensibility as now we know that all ends will be able to process both UDP encapsulated and normal packets always when receiving, so if we later make extensions which enable sending them, we know that it will work with old implementations too. > Looking at this from the point of view of the remote peer, the only > practical solution would be to always employ UDP encapsulation, regardless > of NAT detection. No. There is no way to get IPsec working through that kind of broken firewall. The firewall policy is clearly saying that IPsec is not allowed, thus any way of trying to bypass that policy would be bad... > Now through discussion on the mailing list it appears that this statement > was motivated by a need in MOBIKE to deploy UDP encapsulation when NAT is > not detected. So assuming that we want to cater for this in IPsec, we should > extend IKE to explicitly negotiate UDP encapsulation, rather than having it > rely on the result of NAT detection. Adding full UDP encapsulation negotiation would be too big protocol change to the IKEv2, I do not think we can put it to the current IKEv2bis. It could be added as extension in the future, but I am not sure if such is really needed. Anyways UDP encapsulation negotation with backward compatibility is much simplier if you know that IKEv2 implementations can processes either types of packets always. If you want to force UDP encapsulation, simply fake a NAT on the path (i.e make NAT DETECTION payloads not to match). The new text will allow some cases to work where for some reason two peers do get NAT detection differently. This might be because of bugs (in NAT detection), or because of attacker modifing packets in one direction etc. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
