Re: Comments to draft-ietf-mobike-protocol-00.txt

Mohan Parthasarathy writes:
> > If it was original responder who was initiating the IKE
> > exchange, it does NOT do any updates itself, it simply assumes
> > that original initiator seeing IKE packets coming from
> > different address pair than current one is, initiates a DPD
> > test itself to verify weather the operational address pair is
> > working, and after that will fall back to another address
> >
> As the responder does not know whether there is a NAT
>  in this new path, he can only hope that it works. 

Yes. If there is restricted NAT between and the path breaks down, the
original responder can try to send updates or something, but most
likely he needs to wait for the initiator to detect the problem, and
just hope he does not time out his negotiations before that.

> > In case NAT-T is enabled then implemenations MUST make sure
> > that initiator does DPD in a way that will take care of the
> > updating the other peers addresses in case the NAT mapping is
> > lost. This means that when initiator who is behind NAT start
> > DPD because of the lack of packets from the other peer, he
> 
> This step is confusing to me. I may want to test a new path
> even when the current path is working. The usage of word
> "DPD" is confusing here. The intiator just sends a message that
> looks like DPD (we need to invent a better name for MOBIKE)
> with new addresses.

Path testing can be done with empty INFORMATIONAL exchange (or one
having COOKIE2). That will not have any effect on the other end.

DPD (dead peer detection) can be also done with similar packets.

The operational address pair updates are done with INFORMATIONAL
having COOKIE2 and CHANGE_PATH.

The difference between path test and DPD is really why you are doing
that. Path testing is done when you want to see if some of the other
paths works without modifying the path. DPD is done when you want to
make sure that some of the paths work, i.e. after you have some reason
to belive that something is wrong. Operational address pair update is
done when you know you want to change to some new operational address
pair (and you already know it works because of path test or some other
exchange).

If the initiator is behind the NAT, the DPD can also be used to do to
simulate the dynamic updates of the non MOBIKE NAT-T, by so that we
send the INFORMATIONAL exchange with COOKIE2 and CHANGE_PATH message
as a DPD message, when we suspect that something is wrong. This is
really like using the operational address pair update messages as a DPD
just to make sure the operational address pair matches the NAT mapping
in the NAT box.

I.e. if host A is behind NAT, and host B is the gateway, and host A
and B has MOBIKE IPsec connection established between them. Then the
NAT box is rebooted. The host B will detect that host A starts using
new IP-address, but because this is MOBIKE NAT-T he does not do
anything, simply continues using the old address pair (his packets
will be dropped by NAT).

The Host A notices that he is not getting any messages (IKE or IPsec)
back, and starts DPD to verify that everything is ok. He sends DPD (or
actually operationl address pair update packet is used as DPD) with
COOKIE2 and CHANGE_PATH to the host B. Host B receives that, and
replies to it, and in the same time also updates the operational
address pair to this new one. After that host A can see reply and the
packets start flowing again, and situation is fixed.

Note, that is is very corner case and the reboot of the NAT did
already caused packets to be lost. I.e. the reboot time of the NAT box
could be 30 seconds, and MOBIKE recovery may add another ten seconds
to that (as the Host A might have already noticed during that 30
seconds that he is not getting anything, and might have already
started DPD before the NAT even was up again).

> > includes the N(CHANGE_PATH) to the exchange too, to make sure
> > that the other peer will update its mapping. If it does not
> 
> Don't you have to first detect NAT in the new path ?

Not really, as the we are talking about already existing connection,
with the address pair we have been using before.

I mean I do not really see cases where someone could remove NAT from
the path, in a such way that your IP-address still would remain same.

I do not remember what we decided (or if this was even decided), but I
think we should say that adding or removing NAT to/from the already
working address pair (without changing the addresses) is something we
do not need to support.

> The other end updates only if the initiator is behind NAT.

With my modification the NAT-T would never do automatic update if
MOBIKE is enabled, and other peer would update if and only if he sees
the N(CHANGE_PATH) notify.

> As there are multiple paths and only some paths may be behind a NAT,
> the initiator can update only if a NAT was detected on this new
> path?

The text I was writing there talked about the current operational
address pair having NAT and how to recover that NAT being rebooted. If
we have new address pairs that may or may not have NATs that is
completely different case, and is handled with the text above.

> So, i should be able to test new PATHs with NAT-D payloads without
> using CHANGE_PATH message also ?

Sure. Path tests should have NAT-D payloads, and also COOKIE2
payloads. They MUST NOT have CHANGE_PATH as that would not be path
test anymore, as they would then be a real update for the operational
address pair instead of path test.
-- 
[email protected]