Re: IDci and IDcr payloads with NAT Traversal

[Tero Kivinen <kivinen@iki.fi>]

David Wierbowski writes:
> 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

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.

>  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.

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
> 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.

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
>   and for IDcr is 10.2.2.2

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. 

> 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.

Yes. 

> 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

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
> know HOST A's private address before the negotiation starts.  I

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

> will admit that in the gateway case (my original case) that it
> 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. 

> 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?

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. 

> My concern is that without establishing a convention for
> dealing with IDci and IDcr that we open ourselves up to
> 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."
-- 
kivinen@safenet-inc.com