Paul, > NAT B does not necessarely need
s/necessarely/necessarily/ > replaces the IP address in TSi payloads . . . > replaces the IP addresses in the TSr payloads . . . > it will thus send back traffic selectors having IPN1 and IP2 as their IP addresses . . . . . . As it seems there is no support for my alternative suggestion, I'm ok with this direction. > replaces the IP addresses in the TSr payloads . . . I think it's ok to change this to singular: "the IP address in the TSr payloads". Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Paul Hoffman <paul.hoff...@vpnc.org> To: Tero Kivinen <kivi...@iki.fi>, Scott C Moonen/Raleigh/i...@ibmus Cc: "ipsec@ietf.org" <ipsec@ietf.org> Date: 09/19/2009 06:40 PM Subject: Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP Here is the edited text. Please be sure it is still correct. <section anchor='sect-2.23.1' title='Transport Mode NAT Traversal'> <t>Transport mode used with NAT Traversal requires special handling of the traffic selectors used in the IKEv2. The complete scenario looks like:</t> <figure><artwork><![CDATA[ +------+ +------+ +------+ +------+ |Client| IP1 | NAT | IPN1 IPN2 | NAT | IP2 |Server| |node |<------>| A |<---------->| B |<------->| | +------+ +------+ +------+ +------+ ]]></artwork></figure> <t>(Other scenarios are simplications of this complex case, so this discussion uses the complete scenario.)</t> <t>In this scenario, there are two address translating NATs: NAT A and NAT B. NAT A is dynamic NAT that maps the clients source address IP1 to IPN1. NAT B is static NAT configured so that connections coming to IPN2 address are mapped to the gateways adddress IP2, that is, IPN2 destination address is mapped to IP2. This allows the client to connect to a server by connecting to the IPN2. NAT B does not necessarely need to be a static NAT, but the client needs to know how to connect to the server, and it can only do that if it somehow knows the outer address of the NAT B, that is, the IPN2 address. If NAT B is a static NAT, then its address can be configured to the client's configuration. Other options would be find it using some other protocol (like DNS), but those are outside of scope of IKEv2.</t> <t>In this scenario, both client and server are configured to use transport mode for the traffic originating from the client node and destined to the server.<t> <t>When the client starts creating the IKEv2 SA and Child SA for sending traffic to the server, it has a triggering packet with source IP address of IP1, and a destination IP address of IPN2. Its PAD and SPD needs to have configuration matching those addresses (or wildcard entries covering them). Because this is transport mode, it uses exactly same addresses as the traffic selectors and outer IP address of the IKE packets. For transport mode, it MUST use exactly one IP address in the TSi and TSr payloads. It can have multiple traffic selectors if it has, for example, multiple port ranges that it wants to negotiate, but all TSi entries must use IP1-IP1 range as the IP addresses, and all TSr entries must have the IPN2-IPN2 range as IP the addresses. The first traffic selector of TSi and TSr SHOULD have very specific traffic selectors including protocol and port numbers from the packet triggering the request.</t> <t>NAT A will then replace the source address of the IKE packet from IP1 to IPN2, and NAT B will replace the destination address of the IKE packet from IPN2 to IP2, so when the packet arrives to the server it will still have the exactly same traffic selectors which were sent by the client, but the IP address of the IKE packet has been replaced to IPN1 and IP2.</t> <t>When the server receives this packet, it normally looks the PAD based on the ID and then searches the SPD based on the traffic selectors. Because IP1 does not really mean anything to the server (it is the address client has behind the NAT), it is useless to do lookup based on that if transport mode is used. On the other hand, the server cannot know whether transport mode is allowed by its policy before it finds the matching SPD entry.</t> <t>In this case, the server should first check that as initiator requested transport mode and do address substitution on the traffic selectors. It needs to first store the old traffic selector IP addresses to be used later for the incremental checksum fixup (the IP address in the TSi can be stored as the real source address and the IP address in the TSr can be stored as the real destination address). After that, if the other end was detected as being behind a NAT, the server replaces the IP address in TSi payloads with the IP address obtained from the source address of the IKE packet received (that is, it replaces IP1 in TSi with IPN1). If the server's end was detected to be behind NAT, it replaces the IP addresses in the TSr payloads with the IP address obtained from the destination address of the IKE packet received (thta is, it replaces IPN2 in TSr with IP2).</t> <t>After this address substitution, both the traffic selectors and the IKE UDP source/destination addresses look the same, and the server does SPD lookup based on those new traffic selectors. If an entry is found and it allows transport mode, then that entry is used. If an entry is found but it does not allow transport mode, then the server MAY undo the address substitution and redo the SPD lookup using the original traffic selectors. If the second lookup succeeds, the server will create an SA in tunnel mode using real traffic selectors sent by the other end.</t> <t>This address substitution in transport mode is needed because the SPD is looked up using the addresses that will be seen by the local host. This also will make sure the SAD entries for the tunnel exit checks and return packets is added using the addresses as seen by the local operating system stack.</t> <t>The most common case is that the server's SPD will contain wildcard entries matching any addresses, but this allows also making different SPD entries, for example, for different known NATs outer addresses.</t> <t>After the SPD lookup, the server will do traffic selector narrowing based on the SPD entry it found. It will again use the already-substituted traffic selectors, and it will thus send back traffic selectors having IPN1 and IP2 as their IP addresses; it can still narrow down the protocol number or port ranges used by the traffic selectors. The SAD entry created for the Child SA will have the addresses as seen by the server, namely IPN1 and IP2.</t> <t>When the client receives the server's reply to the Child SA, it will do similar processing. If the transport mode SA was created, the client can store the original returned traffic selectors as real source and destination addresses. It will replace the IP addresses in the traffic selectors with the ones from the IP header of the IKE packet: it will replace IPN1 with IP1 and IP2 with IPN2. Then it will use those traffic selectors when verifying the SA against sent traffic selectors, and when installing the SAD entry.</t> <t>A summary of the rules for NAT-traversal in transport mode is:</t> <figure><artwork><![CDATA[ For the client proposing transport mode: - The TSi entries MUST have exactly one IP address, and that MUST match the source address of the IKE SA. - The TSr entries MUST have exactly one IP address, and that MUST match the destination address of the IKE SA. - The first TSi and TSr traffic selectors SHOULD have very specific traffic selectors including protocol and port numbers from the packet triggering the request. - There MAY be multiple TSi and TSr entries. - If transport mode for the SA was selected (that is, if the server included USE_TRANSPORT_MODE notification in its reply): - Store the original traffic selectors as the real source and destination address. - If the server is behind a NAT, substitute the IP address in the TSr entries with the remote address of the IKE SA. - If the client is behind a NAT, substitute the IP address in the TSi entries with the local address of the IKE SA. - Do address substitution before using those traffic selectors for anything else other than storing original content of them. This includes verification that traffic selectors were narrowed correctly by other end, creation of the SAD entry, and so on. ]]></artwork></figure> <figure><artwork><![CDATA[ For the responder, when transport mode is proposed by client: - Store the original traffic selector IP addresses as real source and destination address in case we need to undo address substitution. - If the client is behind a NAT, substitute the IP address in the TSi entries with the remote address of the IKE SA. - If the server is behind a NAT substitute the IP address in the TSr entries with the local address of the IKE SA. - Do PAD and SPD lookup using the ID and substituted traffic selectors. - If no SPD entry was found, or if found SPD entry does not allow transport mode, undo the traffic selector substitutions. Do PAD and SPD lookup again using the ID and original traffic selectors, but also searching for tunnel mode SPD entry (that is, fall back to tunnel mode). - However, if a transport mode SPD entry was found, do normal traffic selection narrowing based on the substituted traffic selectors and SPD entry. Use the resulting traffic selectors when creating SAD entries, and when sending traffic selectors back to the client. ]]></artwork></figure> </section> --Paul Hoffman, Director --VPN Consortium
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
