Subject: IDci and IDcr payloads with NAT Traversal

From: David Wierbowski <[email-masked]>
Date: Fri, 26 Mar 2004 12:35:06 -0500

I have a question about the ID payloads exchanged in Quick Mode
when NAT Traversal is being utilized in the following scenario:

HOST A ----> GW ----> GW's NAT ----> B's NAT ----> HOST B
10.1.1.123   10.1.1.1                              10.2.2.2

Where:
- The private address for HOST A is 10.1.1.123
- The private address for GW is 10.1.1.1
- GW's NAT translates 10.1.1.1. to x.x.x.x

- The private address for HOST B is 10.2.2.2
- B's NAT translates 10.2.2.2 to y.y.y.y

- GW is trying to create a phase 2 SA with HOST B
  to protect traffic between HOST A and HOST B

My questions are:
- is this a valid scenario?
- if it is, then what IP addresses should be utilized in IDci and IDcr?

Thanks

Dave Wierbowski

z/OS Comm Server Developer

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 28 Mar 2004 12:51:22 +0300

> HOST A ----> GW ----> GW's NAT ----> B's NAT ----> HOST B

Yes, but the discovery of the y.y.y.y or x.x.x.x is outside the scope
of the NAT-T. Lets assume that y.y.y.y is static, known and configured
to the GW (if the GW is the initiator, as it seems in your case).

> - if it is, then what IP addresses should be utilized in IDci and IDcr?

The GW can use IDci = 10.1.1.123 and IDcr = 10.2.2.2, and it needs to
know the 10.2.2.2 from the configuration. I.e. the GW's configuration
would be:

	src = 10.1.1.123, dst = 10.2.2.2,
		enable Tunnel mode NAT-T to address y.y.y.y. 

If there would be overlaps (i.e. host B would also have IP-address of
10.1.1.123, then GW would need to do some kind of NAT for the packets
from host B it sends to the host A).
-- 
[email-masked]

---

From: David Wierbowski <[email-masked]>
Date: Mon, 29 Mar 2004 18:39:01 -0500

>from host B it sends to the host A).

Perhaps I'm reading too much into your answer, but there seems to be
some inconsistencies with IDci and IDcr when NAT Traversal is used.
Let's consider a simpler example:

 HOST A ----> A's NAT ----> B's NAT ----> HOST B
 10.1.1.1                                 10.2.2.2

 Where:
 - The private address for HOST A is 10.1.1.1
 - HOST A's NAT translates 10.1.1.1. to x.x.x.x

 - The private address for HOST B is 10.2.2.2
 - B's NAT translates 10.2.2.2 to y.y.y.y (where y.y.y.y
   is static).

There are two cases:
 1) HOST A is trying create a phase 2 SA with HOST B
    to protect ALL traffic between HOST A and HOST B.

 2) HOST A is trying create a phase 2 SA with HOST B
    to protect TCP traffic between HOST A and HOST B.

In case 1 there is no need to exchange IDci and
IDcr.  They can be assumed to be the IP addresses
of the IKE peers without any implied constraints on
port or protocol.  To me this would imply that both
HOST A and HOST B have a different view of IDci and
IDcr.
- HOST A would think the IP address for IDci is 10.1.1.1
  and for IDcr is y.y.y.y.
- HOST B would think the IP address for IDci is x.x.x.x
  and for IDcr is 10.2.2.2

In case 2 ID payloads must be exchanged (since traffic is
constrained to TCP traffic).  Based on your previous answer
I'm thinking you would expect both HOST A and HOST B to view
IDci as 10.1.1.1 and IDcr as 10.2.2.2.

Based on what the IDs would be if no ID payloads were sent
I would expect that the IDs exchanged in case 2 should be the
same as the IDs implied in case 1.  This seems far more natural to
me as it does not require HOST A to know HOST B's private address
before the negotiation starts and it does not require HOST B to
know HOST A's private address before the negotiation starts.  I
will admit that in the gateway case (my original case) that it
seems as if knowledge of private addresses must be shared.

I think that the "Negotiation of NAT-Traversal in IKE" drafts
needs to include conventions for setting IDci and IDcr.  Perhaps
IDci and IDcr should always be exchanged when NAT is detected?
My concern is that without establishing a convention for
dealing with IDci and IDcr that we open ourselves up to
possible interoperability issues.

Dave Wierbowski

 Phone:
    Tie line:   620-4055
    External:  607-429-4055

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 30 Mar 2004 11:55:26 +0300

>  HOST A ----> A's NAT ----> B's NAT ----> HOST B

Note, as there is two NAT's there the initiastor MUST have specific
configuration about the situation. I.e. it will have configuration
saying if I want to reach host B (ip = 10.2.2.2) create NAT-T
connection using the B's NAt address of y.y.y.y.

> port or protocol.

Yes, for the transport mode. For the tunnel mode that really does not
work, as both ends must agree on the IDs otherwise they will drop the
packet during the tunnel exit checks. Lets assume tunnel mode for now,
so both ends MUST send ID payloads. 

> To me this would imply that both

No, the HOST A will know from the configuration that it wanted to
create SA with 10.2.2.2, and that was simply reached by sending
packets to y.y.y.y, thus it will have IDci 10.1.1.1 and IDcr 10.2.2.2.
It will also notice that it must send IDci and IDcr as they do not
match the IP-addresses. 

> - HOST B would think the IP address for IDci is x.x.x.x

As HOST A will send the IDs the HOST B will know that the other end is
10.1.1.1, and not use implicit IP. 

> IDci as 10.1.1.1 and IDcr as 10.2.2.2.

Yes. 

> before the negotiation starts

How does the implementation on HOST A start? The HOST A needs to have
some configuration which initiates the connection. In normal case it
is the packet send to the HOST B ip-address, which means that HOST A
needs to know the HOST B's ip-address so it can send that packet, and
after trig create the SA with correct host. 

> and it does not require HOST B to

HOST B does not need to know the private address of A, as it can see
it from the ID payloads. 

> seems as if knowledge of private addresses must be shared.

It is the same with this case as long as the tunnel mode is used. 

> IDci and IDcr should always be exchanged when NAT is detected?

For transport mode, you simply ignore the IP-addresses, and you can
put anything you like there (or even use fqdn as IDci and IDcr, so you
do not need to care about the IP-addresses).

For tunnel mode you put the internal IP-addresses, because that is how
the tunnel exit policy is negotiated. 

> possible interoperability issues.

We talked about the IDci and IDcr earlier, but we really couldn't
agree anything else than it depends on the scenario, and almost
everything can be used. Some wanted to use FQDNs, some wanted to say
we simply ignore all IP-numbers in tunnel mode, and some say we leave
them out completely.

I would have liked to add following text:

"If negotiation is using transport mode, then received IP-addresses in
the IDci and IDcr MUST be ignored, i.e. only port and protocol numbers
are used. If negotiation is using tunnel mode, then IDci and IDcr MUST
have IP-address used inside the tunnel i.e. IP-addresses used in the
inner IP-header."
-- 
[email-masked]