RE: IDci and IDcr payloads with NAT Traversal

["William Dixon" <ietf-wd@v6security.com>]

Tero, I agree with your proposed change as long as the peers detect they are
behind NAT. But as you may both know, this is a general interop issue with
IKEv1 regardless of NATs because so many options are allowed as ID types,
the ID payload being an optional payload anyway, and we don't have en
efficient, standardized way to determine what ID type an initiator must use
with a given responder. The reality then is that the vendor's decision about
their policy system controls what IDs they can reasonably accept and thus
who interops with who, with hacks based on vendor ID recognition and some
internal decisions to handle the rest.

I would hope IKEv2 provides clarity to improve the situation. I don't think
it's reasonable that vendors have to build policy systems such that all ID
types are supported in policy, and must be configured to ensure interop. I'm
not sure if there is a way to get a policy system that initiates using FQDN
names to interop safely with one that responds only with IPv4_ADDR. If
everyone supports everything, sure all this can be manually configured...
Certainly it's impractical for my own client as initiator to be manually
configured differently to talk to any destination I may go to in the
Internet. So we should probably also specify how to handle policy transition
from address-dependent policy to names.

Cheers,
Wm

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com 
> [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Tero Kivinen
> Sent: Tuesday, March 30, 2004 3:55 AM
> To: David Wierbowski
> Cc: ipsec@lists.tislabs.com
> Subject: Re: IDci and IDcr payloads with NAT Traversal
> 
> 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
> 
>