Subject: [Mobike] Comments to draft-ietf-mobike-protocol-00.txt

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Jul 2005 19:32:04 +0300

> 1.2  MOBIKE protocol overview
...
>    One important aspect of this information gathering that has to be
>    visible in the messages is determining whether a certain pair of
>    addresses can be used.  IKEv2 Dead Peer Detection (DPD) feature can
>    provide information that the currently used pair does or does not
>    work.  There are, however, some complications in using it for other
>    addresses, and thus MOBIKE adds a new IKEv2 message that can be used
>    to "test" whether some particular pair of addresses works or not,
>    without yet committing to changing the addresses currently in use.

I do not agree on that reason. It is very simple to say in the MOBIKE
protocol, that implementations MUST NOT do dynamical address update if
MOBIKE extensions are enabled, i.e. they MUST always do address
updates only when receiving CHANGE_PATH message in case MOBIKE
extensions are enabled.

That will take care of all the problems using normal IKEv2 packet to
test path.

> 1.3  Terminology
> 
>    Path
> 
>       A particular combination of source IP address and destination IP
>       address (note: this definition does not consider the route taken
>       by the packets in the network).

Any reason why the draft-ietf-mobike-design-02.txt and this document
defined Path differently? The Path from the design draft do include
the route, the Path here matches the more or less the (operantional)
address pair in the design draft.

I think we should try to keep them in sync.

> 2.  MOBIKE protocol exchanges
> 
> 2.1  Signaling support for MOBIKE
> 
>    Implementations that wish to use MOBIKE for a particular IKE_SA MUST
>    include a MOBIKE_SUPPORTED notification in the IKE_SA_INIT request
>    and response messages.
> 
>       Initiator                   Responder
>      -----------                 -----------
>       HDR, SAi1, KEi, Ni,
>            N(MOBIKE_SUPPORTED),
>            [N(NAT_DETECTION_*)]  -->
> 
>                              <--  HDR, SAr1, KEr, Nr,
>                                        [N(NAT_DETECTION_*)],
>                                        [CERTREQ],
>                                        N(MOBIKE_SUPPORTED)

As we are probably going to follow the IKEv2 document style, which
says that payload MUST come in the order they appear in pictures, I
think we might want to keep this and IKEv2 documents consistent. The
CERTREQ is mentioned in the IKEv2 document, so it's order is fixed, so
I would move NAT_DETECTION_*_IP from the reply to the end, i.e:

      Initiator                   Responder
     -----------                 -----------
      HDR, SAi1, KEi, Ni,
           N(MOBIKE_SUPPORTED),
           [N(NAT_DETECTION_*)]  -->

                             <--  HDR, SAr1, KEr, Nr,
                                       [CERTREQ],
                                       N(MOBIKE_SUPPORTED),
                                       [N(NAT_DETECTION_*)]

> 2.3  Changing path of IPsec SAs
> 
>    In MOBIKE, the initiator of the IKE_SA decides what addresses are
>    used in the IPsec SAs.  That is, the responder never updates any
>    IPsec SAs without receiving an explicit CHANGE_PATH request from the
>    initiator.  (As described below, the responder can, however, update
>    the IKE_SA in some circumstances.)

I think we should say that responder never updates IKE_SA without
explicit CHANGE_PATH. Not by any dynamic updates because of NAT-T code
or any other reason. We simpy say that it always keeps the IKE_SA
addresses intact. 

>    The description in this section assumes that the initiator has
>    already decided what the new addresses should be.  How this decision
>    is made is beyond the scope of this specification.  When this
>    decision has been made, the initiator
> 
>    o  Updates the IKE_SA and IPsec SAs with the new addresses, and sets
>       the "pending_update" flag in the IKE_SA.
> 
>    o  If NAT Traversal is not enabled, and the responder supports NAT
>       Traversal (as indicated by NAT detection payloads in the
>       IKE_SA_INIT exchange), and the initiator either suspects or knows
>       that a NAT is likely to be present, enables NAT Traversal.

I assume that this implicitly means that retransmissions sent during
that time are sent to new address instead of old one? This is not
really mentioned anywhere, and it needs a lot of text more to describe
that.

That same text is also needed if we want to get rid of the PATH_TEST
exchange completely.

This text should be enough:
----------------------------------------------------------------------
	When sending any IKE packets we first try the operational
	address pair. If we do not get reply back from that we try all
	other address pairs until we get reply back, or the exchange
	times out, in which case the IKE SA is deleted. The order in
	which the address pairs are tried is implementation specific,
	and can use information from various places.

	The other end receiving those packets, should reply to all of
	them it receives, with the addresses and ports reversed.
	Recipient of any other packet than N(CHANGE_PATH) MUST NOT
	cause any update in the IKE_SA or IPsec SA addresses (also in
	case when NAT-T is used). 

	This way any IKE packet can be used to test weather the path
	works or not. If during the sending of IKE packet we detect
	that the operational address pair is not working anymore, the
	original initiator (not the exchange initiator) should take
	actions to fix the situation by finding new operational
	address pair, and sending N(CHANGE_PATH) for the new
	operational address pair.

	If it was original initiator who was initiating the IKE
	exchange, then after the exchange finishes it already knows
	the new address pair which works, so he can simply send
	N(CHANGE_PATH) to update to new working operational address
	pair.

	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
	pairs, and result update to the operational address pair in
	initiator, it will then send N(CHANGE_PATH) notify to update
	the operational address pair.

	If operational address pair is broken down when we are sending
	N(CHANGE_PATH) exchange, then it is possible that the
	responder will be updated to the some other address pair than
	what initiator originally intended (in case of uni-directional
	connection, i.e. responder getting the first N(CHANGE_PATH)
	in, but initiator not getting the reply back, thus trying
	other addresses, and finally getting reply back). In this case
	the initiator should immediately update his own operational
	address pair to the one that is working, and do another
	N(CHANGE_PATH) exchange with the known working address pair to
	make sure that the initiator and responder do agree on the
	address pair. Only after when he gets reply back from the
	address pair he intended to use in the first place, he can be
	sure that both peers agree on the address pair.

	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
	includes the N(CHANGE_PATH) to the exchange too, to make sure
	that the other peer will update its mapping. If it does not
	get reply back using operational address pair, it tries other
	address pairs, and if it does get reply back it does normal
	operation, i.e. restarts the N(CHANGE_PATH) for that new
	operational address pair.
----------------------------------------------------------------------

>    Note that if the responder has NAT Traversal enabled, it can update
>    the addresses in both the IKE_SA and IPsec SAs as usual (if it
>    implements the "SHOULD" from [IKEv2] Section 2.23.

There is no reason for the other end to enable the SHOULD in case the
MOBIKE is used. We can simply say that it MUST NOT do the dynamic
address updates in case MOBIKE is enabled.

> 2.4  Updating additional addresses
...
>    There is one additional complication: when the responder wants to
>    send a new additional address list, the currently used path may no
>    longer work.  In this case, the responder uses the additional address
>    list received from the initiator, the list of its own addresses, and,
>    if necessary, the path testing feature (see Section 2.5) to determine
>    a path that works, updates the addresses in the IKE_SA (but not IPsec
>    SAs), and then sends the INFORMATIONAL request.  This is the only
>    time the responder uses the additional address list received from the
>    initiator.

This is no way only related to the updating addresses, it might be
also break down during any other exchange, and if the responder does
not do try all address pairs when sending IKE packets, it will cause
IKE SA to deleted because of timed out exchange unless the initiators
DPD timers are much shorter than responders negotiation timeout
timers.

I mean if initiator does DPD, and notices that everything is fine,
then address pair breaks down, and then responder starts sending some
IKE packet. If this IKE packet manages to time out before the next DPD
has started, and detected the problem, and found the new working
address pair, and sent an address update by N(CHANGE_PATH) then the
responder will delete the IKE SA.

There are cases where the responder cannot do anything, because of the
NATs, so in those cases this will happen anyways, but if there is no
NATs preventing original responder for sending packets to original
initiator then the original responder can simply try other address
pairs, to see if them work. If not, then delete the IKE SA, if one of
them work, fine, he did get his operation done, and original initiator
probably got some hint about something being wrong...

If we decide that we do not need this feature, then we can simply
leave out the address lists in the responder side completely, and say
that responder will not try to fix any situations, and it will not
support break-before-make style movement to new addresses unknown by
the initiator. 

> 2.5  Path testing

If we take my previous text in 2.3, then this section would simply
say:

	Any IKE packets can be used for path testing as long as it has
	property that responder cannot generate reply packet to it
	without seeing the request packet. Normally any INFORMATIONAL
	exchange with N(COOKIE2) is enough. 

>    MOBIKE introduces a new IKEv2 exchange type, PATH_TEST, for testing
>    connectivity.  This exchange is not part of any IKE_SA, so it is not
>    cryptographically protected.  It also does not result in the
>    responder keeping any state.

I do not like this non-protected exchange, as its security
implications are not known. For example the text below, does not say
what to do if the N(COOKIE2) are not matching. The other place said we
tear down IKE SA, but we do not want to do it here. 

>    The reason for introducing a new exchange type, instead of using
>    INFORMATIONAL exchanges, is to simplify implementations by allowing
>    MOBIKE to work with window size 1.

I do not think it will simplify implementations at all. We need the
similar processing of the outgoing IKE exchanges anyways, i.e. each
IKE exchange needs to be able to be retransmitted using another
address pair, thus doing it 2-3 times (first with broken address pair,
then detecting that address pair does not work, and finding out new
address pair using PATH_TEST and then chaging to that new address
pair, and perhaps that new pair broke down before we managed to use
it) or 10 times (use the IKE packet to do the PATH_TEST, i.e. iterate
through all addess pairs) does not really make it more complicated.

We do not need window size above 1 even for those.

Also taking care of the dynamic updates in case if NAT-T is easy, we
simply say you MUST NOT do those if MOBIKE is enabled.

If we simply want to test weather the address pair works we do
INFORMATIONAL without N(CHANGE_PATH).

> 2.6  Return routability check
...
>    To ensure that the peer cannot generate the correct INFORMATIONAL
>    response without seeing the request, a new payload is added to all
>    INFORMATIONAL messages.  The sender of an INFORMATIONAL request MUST
>    include a COOKIE2 notification payload, and the recipient of an
>    INFORMATIONAL request MUST copy the payload as-is to the response.
>    When processing the response, the original sender MUST verify that
>    the value is the same one as sent.  If the values do not match, the
>    IKE_SA MUST be closed.

I donot think we need to moify all INFORMATIONAL exhcnages to include
N(COOKIE2), only those that are used for the return routability
checks. 

>    There is one additional issue that must be taken into account.  If
>    the destination address in the IKE_SA has been updated after the
>    INFORMATIONAL request was sent, then it is possible that the request
>    has been sent to several different addresses.  In this case,
>    receiving the INFORMATIONAL response does not tell which address is
>    the working one; thus, a new INFORMATIONAL request needs to be sent.

This should probably be clarified better, i.e. if we fall back to the
other addresses, then the malicious peer can take those later messages
that did reach him and send them back using different address pair,
i.e. faking the reply of return routability check.

There is no description here what should be done in that case. We need
to send ACK to the N(CHANGE_PATH) quite soon, we cannot wait for the
return routability check to finish, as it might be so that the
initiator sends N(CHANGE_PATH) and then address pair stops working,
thus we cannot do return routability check, but on the other hand
initiator cannot do anything to fix the situation as he might have
window size of 1, and cannot send another N(CHANGE_PATH) before the
one that is being processed is ACK'ed.

So we probably want to return ACK to N(CHANGE_PATH) immediately, but
update the actual IP-addresses only after the return routability
checks finish, and if during that time we get new N(CHANGE_PATH) we
simply change the base address where to do return routability checks. 

> 2.7  NAT prevention
...
>    If the IKE_SA_INIT request included NAT_DETECTION_*_IP payloads but
>    no NAT_PREVENTION payload, the situation is different since the
>    initiator may at this point change from port 500 to 4500.  In this
>    case, the responder initializes (local_address, local_port,
>    peer_address, peer_port) from the first IKE_AUTH request.  It may
>    also decide to perform a return routability check soon after the
>    IKE_AUTH exchanges have been completed.

Why does it need to do the return routability check? IKEv2 NAT-T does
not do return routability checks there, why should we do? Note, that
the initiator will not see any IPsec packets thus he cannot for
example start TCP sessions, as those are not retransmittede to
secondary addresses. I cannot really see how he could mount any real
attack at this phase.

>    IKEv2 requires that if an IPsec endpoint discovers a NAT between it
>    and its correspondent, it MUST send all subsequent traffic to and
>    from port 4500.  To simplify things, implementations that support
>    both this specification and NAT Traversal MUST change to port 4500 if
>    the correspondent also supports both, even if no NAT was detected
>    between them.

What does that simplify? In normal case implementations will never do
that as it wastes 4 bytes for each IKE packet.

> 3.  Payload formats
> 
> 3.1  MOBIKE_SUPPORTED notification payload
> 
>    The MOBIKE_SUPPORTED notification payload is included in the
>    IKE_SA_INIT messages to indicate that the implementation supports
>    this specification.
> 
>    The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA
>    (16396..40959).  The Protocol ID field is set to one (1), and SPI
>    Size is set to zero.  There is no data associated with this Notify
>    type.

How about adding 32 bits of data, with the MOBIKE version number,
initially 0?

Also I think this notify does not relate to existing SA, so the
protocol ID should be 0.

> 3.2  ADDITIONAL_ADDRESS notification payload
> 
>    Both initiator and responder can include ADDITIONAL_ADDRESS payloads
>    in the IKE_AUTH exchange and INFORMATIONAL exchange request messages;
>    see Section 2.2 and Section 2.4 for more detailed description.
> 
>    The Notify Message Type for ADDITIONAL_ADDRESS is TBD-BY-IANA
>    (16396..40959).  The Protocol ID field is set to one (1), and SPI
>    Size is set to zero.  The data associated with this Notify type is
>    either an IPv4 address or an IPv6 address; the type is determined by
>    the payload length.

I think it is better to take 2 different notification types for IPv4
and IPv6. Checking the lenght is bad, as then we cannot extend the
structure later by adding more information to the notification data.
The design draft asks this in the section 5.11, i.e. make the format
so we can extend in the future it with new data, like load balancing
weight (currently out of scope, but one of the possible future works).

Also I think this notify does not relate to existing SA, so the
protocol ID should be 0.

> 3.3  CHANGE_PATH notification payload
> 
>    This payload is included in INFORMATIONAL exchange requests sent by
>    the initiator of the IKE_SA to update addresses of the IKE_SA and
>    IPsec SAs (see Section 2.3).
> 
>    The Notify Message Type for CHANGE_PATH is TBD-BY-IANA
>    (16396..40959).  The Protocol ID field is set to one (1), and SPI
>    Size is set to zero.  There is no data associated with this Notify
>    type.

Also I think this notify does not relate to existing SA, so the
protocol ID should be 0.

> 3.4  UNACCEPTABLE_PATH notification payload
> 
>    The responder can include this notification payload in an
>    INFORMATIONAL exchange response to indicate that the address change
>    in the corresponding request message (which contained a CHANGE_PATH
>    notification payload) was not carried out.
> 
>    The Notify Message Type for UNACCEPTABLE_PATH is TBD-BY-IANA
>    (40..8191).  The Protocol ID field is set to one (1), and SPI Size is
>    set to zero.  There is no data associated with this Notify type.

There is a problem in case the UNACCEPTABLE_PATH is not for address in
the IP header but some other address pair. I mean the initiator sends
packet with IPA1, IPB1 N(CHANGE_PATH). That reaches the responder, but
he decides to send N(UNACCEPTABLE_PATH) back. The reply never reaches
the initiator because of uni-directional connection or something. The
initiator retransmits the packet with IPA2, IPB2 N(CHANGE_PATH). This
would be ok for the responder, but as he has already generated the
reply N(UNACCEPTABLE_PATH) he will retransmit that back. This will
reach the initiator and he will be receiving wrong information which
path was unacceptable.

Fixing this is quite simply, we add the address pair that was
unacceptable to the notify data. In case there is NAT in the path the
responder might not recognize all the addresses, but in case of no
NATs it immediately knows which address pair wasn't acceptable. 

Also I think this notify does not relate to existing SA, so the
protocol ID should be 0.

> 3.5  COOKIE2 notification payload
> 
>    This payload is included in all INFORMATIONAL exchange messages for
>    return routability check purposes (see Section 2.6).  It is also used
>    in PATH_TEST messages to match requests and responses (see
>    Section 2.5).

I would say we define this in more generic way:
----------------------------------------------------------------------
	This payload MAY be included in any IKEv2 exchange. The data
	associated with this notification MUST be between 8 and 64
	octets in length (inclusive), and MUST be chosen in a way that
	is unpredictable to the recipient. The recipient MUST copy
	this notification to his reply packet. The negotation
	initiator MUST then check that the N(COOKIE2) received from
	the other peer matches the one he sent out.

	This message MUST be included in the IKE exchanges used as a
	return routability check.

	The Notify Message Type for this message is TBD-BY-IANA
	(16396..40959). The Protocol ID field is set to zero (0), and
	SPI Size is set to zero.
----------------------------------------------------------------------

(already changed protocol id to zero).

> 3.6  NAT_PREVENTION notification payload
> 
>    See Section 2.7 for a description of this payload.
> 
>    The data associated with this notification is the SHA-1 hash
>    [FIPS180-2] of the following data: IKE SPIs (in the order they appear
>    in the header), the IP address and port from which the packet was
>    sent, and the IP address and port to which the packet was sent.  The
>    Notify Message Type for this message is TBD-BY-IANA (16396..40959).
>    The Protocol ID field is set to one (1), and SPI Size is set to zero.

Also I think this notify does not relate to existing SA, so the
protocol ID should be 0.

> 3.7  NAT_PREVENTED notification payload
> 
>    See Section 2.7 for a description of this payload.
> 
>    The Notify Message Type for NAT_PREVENTED is TBD-BY-IANA (40..8191).
>    The Protocol ID field is set to one (1), and SPI Size is set to zero.
>    There is no data associated with this Notify type.

Also I think this notify does not relate to existing SA, so the
protocol ID should be 0.

> 4.  Security considerations
...
>    Protection of MOBIKE payloads
> 
>       The payloads used in MOBIKE are encrypted, integrity protected,
>       and replay protected.  This assures that no one except the
>       participants can, for instance, give a control message to change
>       the addresses.

This is not true, as PATH_TEST packets in the current document are not
encrypted or proteced. This should be mentioned here, and security
analysis of all possible attacks this new protocol might cause should
be done.

I remember that I promised to write a section describing how to do the
protocol without nerw PATH_TEST protocol, but instead of using the any
IKE packets with that, and with working for window size 1. The text up
there in section 2.3 comments should actually be enough. I do not
think we need more text, but we can remove all references to the
PATH_TEST exchange. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 12 Jul 2005 22:13:49 -0700

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

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

> that the other peer will update its mapping. If it does not

Don't you have to first detect NAT in the new path ? The other end updates
only if the initiator is behind NAT.  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 ?

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

-mohan

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 13 Jul 2005 12:04:32 +0300

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

> looks like DPD (we need to invent a better name for MOBIKE)

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

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

> 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-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 14 Jul 2005 17:33:18 -0700

> packets start flowing again, and situation is fixed.
If the operational pair is not working and the intiator is behind NAT,
it could be multiple reasons : NAT reboot, some router crashed etc.
You assumed that NAT rebooted above. If the NAT did not reboot,
then the PATH did not really change. In this case, the initiator would
still not see any response and hence try a new PATH later. Does this
mean that the initiator behind NAT always have to try sending
DPD with CHANGE_PATH and then try new PATH ? If we think
this is a corner case, i am not sure whether it is worth it.

-mohan

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 15 Jul 2005 12:11:21 +0300

Mohan Parthasarathy writes:
> still not see any response and hence try a new PATH later.

The first thing that initiator does when it does not see packets is to
start DPD on the operational address pair. It does this regardless if
it is behind NAT or not. The only change there is that if it is behind
NAT he should put CHANGE_PATH notify there too.

If the problem was NAT booting, then the CHANGE_PATH will update the
responder side (it is processed there as normal IP-address change). If
the lack of traffic was because of some other reason, then the
CHANGE_PATH does not do anything, as it would only change the
operational address pair to be same that as it is already now (i.e. no
operation for the responder side, this situation can happen quite
often in other cases too, so responder must be able to process that
correctly).

If this was because path having NAT broke down, then the DPD will
try other address pairs too when it cannot get packets back with the
current operational address pair. Then initiator will find the proper
working address pair, and finishe the DPD and do the another
CHANGE_PATH to that (as specified in normal case where the packet
having CHANGE_PATH is retransmitted to multiple address pairs).

So the only change really is the addition of CHANGE_PATH in the DPD
packet if behind NAT.

> Does this mean that the initiator behind NAT always have to try
> sending DPD with CHANGE_PATH and then try new PATH ?

Yes, but actually the DPD with CHANGE_PATH will be used to search for
the new path. I.e after it finishes we have new address pair that
works, because we do retransmit that packet to other addresses too.

> If we think this is a corner case, i am not sure whether it is worth
> it.

Nat booting is corner case, but adding the CHANGE_PATH to DPD when
behind NAT is so small change that I think we should do it. All the
other processing is still same than in normal case. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike