Re: Do we need text about failing RR

Jari Arkko writes:
> >So we probably want to say something about this, as it do require the
> >initiator to understand that even when it is getting ESP packets in it
> >might need to start DPD in case the IP addresses of the ESP packets
> >are different from what he thinks they should be.
> >  
> >
> Isn't that already stated somewhere? Seems like its a
> part of the NAT behaviour...

At least it is not mentioned in the NAT-T drafts and I do not think it
is mentioned in the IKEv2 draft either. Protocol draft says:
----------------------------------------------------------------------
   IKEv2 performs Dead Peer Detection (DPD) if there has recently been
   only outgoing traffic on all of the SAs associated with the IKE_SA.
----------------------------------------------------------------------

and that is under NAT-T. IKEv2 draft says:
----------------------------------------------------------------------
   ...     If there has only been outgoing traffic on all of
   the SAs associated with an IKE_SA, it is essential to confirm
   liveness of the other endpoint to avoid black holes. If no
   cryptographically protected messages have been received on an IKE_SA
   or any of its CHILD_SAs recently, the system needs to perform a
   liveness check in order to prevent sending messages to a dead peer.
   Receipt of a fresh cryptographically protected message on an IKE_SA
   or any of its CHILD_SAs assures liveness of the IKE_SA and all of its
   CHILD_SAs. Note that this places requirements on the failure modes of
   an IKE endpoint. An implementation MUST NOT continue sending on any
   SA if some failure prevents it from receiving on all of the
   associated SAs. If CHILD_SAs can fail independently from one another
   without the associated IKE_SA being able to send a delete message,
   then they MUST be negotiated by separate IKE_SAs.
----------------------------------------------------------------------

So that does not say anything about the IP-addresses.

I think we need some paragraph about that to the mobike draft. 

> Anyway, I believe we do need to say something about
> the case that you mentioned. It is indeed possible that
> an update fails in any of its stages, including RR. What
> I would suggest is that if you don't complete the update
> then you continue operating as if it didn't happen, and
> be prepared to accept/initiate another address update.

The problem in the failing in the RR step is that it is negotiatiation
initiated by the responder, thus it cannot fall back to other
addresses. It is also normal IKEv2 message, which means it must get
reply back or otherwise the whole IKE SA is deleted. So we cannot fail
that RR, we must finish it, and we can only finish it with the help of
initiator noticing that the path does not work, and falling back to
some other path. 
-- 
[email protected]