[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: doubt on draft-ietf-ipsec-nat-t-ike-01.txt



lokeshnb@intotoinc.com ("Lokesh") writes:
 > Hi All,

Hi.

 > Following is a doubt regrading ID draft-ietf-ipsec-nat-t-ike-01
 > It proposes, that sending party should calculate NAT-D paylods for
 > both Destination and source(its own) IP address and port pairs.
 > that is HASH = HASH( CKY-I | CKY-R | IP | Port)
 > So in Normal case,(host is not multihomed) there  will be
 >  two NAT-D  payloads.
 > I want to know why it is proposed to send 2 NAT-D payloads?
 > For me , it looks that, there is not need for First NAT-D payload
 > which is Hash on Destination IP and port.
 > because Destination IP and Ports are not going to change in NAT,
[*]
 > only Source ip and source ports are changed. sending party can send only
 > Second NAT-D payload (HASH on its own IP and src port) , and receiving
 > can determine occurance of NAT as follows.  take src ip and src port
 > selectors from incoming packet, prepare HASH on them and compare with
 > HASH or NAT-D payload sent by other peer. If match is ok, there is no
 > NAT, if it fails, there is a NAT.
 > 
 > Is that Ok? or Am I   missing some point here? if so correct me please.

[*] Oh? Is there a guarantee about this somewhere?

Consider this:

  initiator ---> contacts 1.2.3.4 ---> static nat ---> responder (2.3.4.5)

Obviously, the responder is behind the NAT, and not the initiator.  It
should be possible to run IPsec regardless given the payloads specified in
the draft, but not with changes you specify.

Also, in normal NAT case, with your changes, the other side would NOT know
about the NAT; obviously, when the responder sends his src address, it
stays the same to the initiator (as nobody alters it) and initiator
wouldn't know of presence of a NAT device, unless responder sent something
else than just normal address as response (like the `DECISION' payload in
my older draft).

 > Thanks
 > -Lokesh

-Markus

-- 
Markus Stenberg <stenberg@ssh.com> of SSH Communications Security (www.ssh.com)
SSH 囲碁先生