Hi Scott When writing remote access VPN clients (running on phones, PCs, tablets, probably not z/OS) it's usually safe to assume that the peer (a gateway) supports NAT-T. This is because on the real Internet, a RAS that does not support NAT-T simply doesn't work. NATs are everywhere.
So it's possible to write a simplified client, that only does NAT-T (no ESP and no UDP port 500) and it doesn't even need to bother with the NAT_DETECTION payloads. Allowing UDP 4500 even for the IKE_SA_INIT exchange allows such clients, and I don't see a reason to forbid them. Yes, they are not interoperable with perfectly legitimate IKEv2 implementations that do not support NAT-T, but that doesn't matter, because those minimal implementations are not fit to be RAS. On Jan 12, 2010, at 4:21 PM, Scott C Moonen wrote: Tero, > > 2) Disallow floating on IKE_SA_INIT unless . . . > Why do you want to disallow that? . . . > > > 3) Disallow this elective use of UDP-encap unless . . . > Again why do that? I guess I'm thinking more about what is advisable (without out-of-band knowledge or inference) than what is permissible, so that may be out of scope. And I should have said "recommend against" rather than "disallow". Scott Moonen (smoo...@us.ibm.com<mailto:smoo...@us.ibm.com>) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Tero Kivinen <kivi...@iki.fi<mailto:kivi...@iki.fi>> To: Scott C Moonen/Raleigh/i...@ibmus Cc: ipsec@ietf.org<mailto:ipsec@ietf.org> Date: 01/12/2010 03:36 AM Subject: Re: [IPsec] ikev2bis clarification on port floating ________________________________ 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<mailto:kivi...@iki.fi> _______________________________________________ IPsec mailing list IPsec@ietf.org<mailto:IPsec@ietf.org> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
