Re: IDci and IDcr payloads with NAT Traversal

[David Wierbowski <wierbows@us.ibm.com>]

>> 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.
>
If IPSec was not in the picture and HOST A wanted to send a
packet to HOST B it would send the packet to y.y.y.y and
not to 10.2.2.2.  I do not see why this should have to change just
because IPSec is in the picture.  Why should HOST A need to know
that he is really sending a packet to 10.2.2.2?  There is no reason
to require that HOST A should know the network topology behind a NAT
sitting in front of HOST B, but that is what you are requiring.

>> - 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.
Without IPSec in this picture HOST A would know his private address and
and HOST B's public address.  Likewise HOST B would know his private
address and HOST A's public address.  I don't really see why IPSec should
change those configuration requirements.

>
>> 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.
>
HOST A would continue to initiate a connection to y.y.y.y, just like
he would do if IPSec was not in the picture.  The IKE NAT traversal
draft allows an IPSec endpoint to learn that it is behind a NAT.  When
an IPSec endpoint learns that it is behind a NAT it should realize that
the destination IP address in the inner header of a UDP encapsulated tunnel
mode packet received may not agree with the IDci and IDcr payloads sent by
a peer.
>> 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."
I do not think such a statement is useful.  I believe we disagree on what
the IP addresses in the inner header would contain.  I do not think that
HOST A should need to know about 10.2.2.2 so I would expect the destination
address in the inner header of an IP packet sent from HOST A to HOST B
would
contain y.y.y.y and you would expect it to contain 10.2.2.2.


Dave Wierbowski


z/OS Comm Server Developer