Dondeti, Lakshminath wrote:
>
> I did not think of the 'sending of protected TCP ACKs to fake
> liveness' :-), but that prompts me to say that RR should
> require the client to decrypt the RR request message, and send
> a reply with information from within the request message. If
> the protocol were to send an empty informational message,
> wouldn't the client be able to "expect the time of the
> request" and send a valid "response?"
This is actually a very good point! It seems that in IKEv2
an empty informational exchange does not guarantee RR,
since the client could generate the response without
actually seeing the request...
Perhaps we could re-use the COOKIE Notify payload for this?
That is, when the gateway receives a request to update the SAs,
it could reply with a COOKIE payload and the client would
re-send the request with the cookie? This way, RR could be also
skipped if necessary (for instance when switching back to an
address that was already tested recently).
This, of course, means that the address update request has
to be sent from the new address (since the reply containing the
cookie goes to the source address of the IKEv2 packet). This
may also complicate "path failover" since it may be possible
that a packet containing an address update request would be
used for path testing...
Personally I think it would be also acceptable to do the RR
check after changing the address. That is, the gateway updates
the SAs immediately, but then sends a separate informational
exchange containing some kind of cookie. What do others think
about this?
Best regards,
Pasi
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.