Clarification of potential NAT multiple client solutions

["Brian Swander" <briansw@windows.microsoft.com>]

We have had requests to clarify potential solutions to problem of multiple clients behind the same NAT simultaneously connecting to the same destination IP address. draft-ietf-ipsec-udp-encaps-03.txt sections 5.2 and 5.3 say you MUST avoid the problem.  Therefore you must implement some kind of solution for this problem.  If your solution is not to support the scenario, you can still interoperate with others and support just one client behind the same NAT with SA state to you at any one time.
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-03.txt

As this isn't a wire protocol matter, but a local implementation matter, specification of the mechanisms do not belong in the draft itself.  A list of options is below.  And you'll see that this mail has been through our legal department because of there are some known and perhaps unknown IPR issues with implementation techniques.  Choosing an option will likely depend on the scenarios for which you use/support IPsec NAT-T.  This is not meant to be exhaustive, so other solutions may exist.

Bottom line is that there are a variety of solutions for this scenario.  So I don't see the IPR issues relating to solutions for this one scenario as blocking the progress of NAT-T drafts on standards track.

For ESP transport mode:
1. implement a built-in NAT (network address translation) above IPsec decapsulation.  SSH may have intellectual property rights relating to this implementation technique.  See their IPR notice on the IETF web site for the details.

2. implement a built-in NAPT (network address port translation) above IPsec decapsulation.  Microsoft may have intellectual property rights relating to this implementation technique.  See the Microsoft IPR notice on the IETF web site for the details.

3. upper layer protocol awareness of the inbound & outbound IPsec SA (where it doesn't use source IP and source port as the session identifier. E.g. L2TP session ID mapped to the IPsec SA pair which doesn't use the UDP source port or source IP address for peer uniqueness) 

4. application integration with IKE initiation such that it can rebind to a different source port if the IKE quick mode SA proposal is rejected by the responder, then repropose the new QM selector.  Microsoft may have intellectual property rights relating to this implementation technique.  See the Microsoft IPR notice on the IETF web site for the details.

5. an initiator may decide not to request transport mode once NAT is detected and instead request a tunnel mode SA.  This may be a retry after transport mode is denied by the responder, or it may be the initiator's choice to propose a tunnel SA initially.  This is no more difficult than knowing whether to propose transport mode or tunnel mode without NAT.  If for some reason the responder prefers or requires tunnel mode for NAT traversal, it must reject the quick mode SA proposal for transport mode.  

6. don't support the scenario of multiple clients behind the same NAT simultaneously.  Simply fail the second attempt at Main Mode or the Quick Mode.  A NAT-OA payload in Quick Mode would certainly be helpful to discover uniqueness of clients behind NATs.  But you could persist the Main Mode NAT-D payload hash to determine the difference between a Main Mode rekey (same hash) with a new MM from a different peer behind the same NAT (different hash).  Accept only 1 concurrent IKE SA from the same private IP address, leave the incoming address alone in the IP header, but fix the pseudoheader checksum for TCP & UDP.  If you support multiple Main Modes, then an initial contact notify payload sent under the protection of the ISAKMP SA is valid only for the identity of the initiator, to delete prior Main Modes from that same identity and any related QM state for those Main Modes.  Cleanup action due to initial contact can not be taken based on the source IP address of the initiator.

For ESP tunnel mode:
1. same NAT option above

2. same NAPT options above

3. it may be feasible in some scenarios for upper layers to know the IPsec SA, be it transport mode or tunnel mode.

4. if an initiator is capable of draft-ietf-ipsec-dhcp-13.txt, then it supports the capability of being assigned an address through it's tunnel SA with the responder.  The initiator may initially request an internal address via the DHCP-IPsec method, regardless of whether it knows it is behind a NAT.  Or it may re-initiate an IKE quick mode negotiation for DHCP tunnel SA after the responder fails the quick mode SA transport mode proposal, either when NAT-OA payload is sent or because it discovers from NAT-D the initiator is behind a NAT and it's local configuration/policy will only accept draft-ietf-ipsec-dhcp-13.txt method of connecting through NAT.

5. don't support the scenario.

If the initiator proposes tunnel mode, the responder is under no obligation to perform NAT on the tunneled traffic or to support draft-ietf-ipsec-dhcp-13.txt for assigning an address to the initiator.  Rather it is the initiator's decision based on it's capabilities and the scenario of usage and it's configuration how best to encapsulate traffic once NAT is detected.  Vendor ID payloads may be used to advertise certain capabilities to the initiator that are vendor or implementation specific.


I'm required to append this clause by our legal department since this talks about implementation techniques, and notes IPR issues with some of these techniques:

This is to advise the IETF that Microsoft believes it may have patent rights (patent(s) and/or patent application(s) pending or soon to be filed) that relate to the technologies discussed in this submission. Microsoft is willing to negotiate licenses with interested parties to such patent rights as follows:
 
If part(s) of this contribution is(are) included in an IETF standard and Microsoft has patent rights that are essential to implement such standard, Microsoft is prepared to grant a license to the necessary claims of Microsoft patent rights, to the extent that such claims are required to implement that IETF standard, on a royalty-free basis with other reasonable and non-discriminatory terms and conditions, provided a reciprocal license is granted to Microsoft for any patent claims necessary to implement the following IETF nat traversal drafts: draft-ietf-ipsec-nat-t-ike-03.txt and draft-ietf-ipsec-udp-encaps-03.txt.


Microsoft's contribution and the information contained herein is provided on an "AS IS" basis and the contributors and Microsoft Corporation DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 
Any questions regarding this communication should be directed to:
 
            Microsoft Standards Group
            c/o Dawna Hoerle
            Microsoft Corporation
            One Microsoft Way
            Bldg. 114/2306
            Redmond, WA 98052