Scott C Moonen writes: > Further question -- is it ok for the IKE negotiation *not* to float and > then for the ESP traffic to later arrive UDP-encapped on port 4500?
Yes, provided the NAT_DETECTION_* payloads were exchanged, (i.e. the implementation knows other end supports NAT-T). > It seems like it would be wise not to send UDP-encapped ESP unless > you've already verified that the 4500-4500 port pairing works during > an IKE exchange. But the text in section 2.31 doesn't seem to > exclude that possibility. That was the intention, i.e. even when there was no NAT (regardless whether you use port 500 or 4500), but other end did support NAT-T (i.e. NAT_DETECTION_* payloads were exchanged), then you can use either normal ESP packets, or UDP encapsulated ESP packets on port 4500. This is something that is already required for MOBIKE, as with MOBIKE the host might suddenly notice that you moved to new IP-address which do have NAT, thus you might need to enable NAT-T. On the other hand with MOBIKE you always change to use port 4500 in the beginning to simplify things. The current text does not say when you would be sending such packets, it just says that you MUST be able to receive them. > Personally, I think we should: > > 1) Rephrase the "non-UDP encapsulated packets" wording as Dan requested. > Possible starting point: "receive and process IPsec packets with or > without UDP encapsulation at any time." That change seems to be good. > 2) Disallow floating on IKE_SA_INIT unless you have prior knowledge the > peer supports NAT traversal (i.e., an existing SA is being authenticated, > which itself exchanged NAT_DETECTION_* payloads even if it may not have > detected a NAT). Why do you want to disallow that? You might not have prior knowledge, but you might have good hints that other end needs to support NAT-T or otherwise communications does not work so better start at port 4500 directly. Also some minimal implementations supporting NAT-T could always start at port 4500 as they do not support normal IPsec at all, only UDP encapsulated IPsec and they always act as they were behind NAT. > 3) Disallow this elective use of UDP-encap unless you have already floated > the IKE SA. Again why do that? I think it is easier to just make it so that you can always use normal IPsec or UDP encapsulated IPsec if you support NAT-T regardless whether you have changed ports etc... I.e if you get packet to your IKE NAT port (4500) you check the SPI and if it is there you strip UDP header and pass it to IPsec engine. If there is 4 bytes of zeros in the beginning then you pass it to the UDP stack. No need to check whether there was NAT-T enabled for this specific host etc. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec