Subject: [IPsec] Bis issue #14: Bounding the retransmit time

From: Yaron Sheffer <[email-masked]>
Date: Wed, 28 Jan 2009 00:49:47 +0200

2.1. Use of Retransmission Timers

...

For every pair of IKE messages, the initiator is responsible for retransmission in the event of a timeout. The responder MUST never retransmit a response unless it receives a retransmission of the request. In that event, the responder MUST ignore the retransmitted request except insofar as it triggers a retransmission of the response. The initiator MUST remember each request until it receives the corresponding response. The responder MUST remember each response until it receives a request whose sequence number is larger than or equal to the sequence number in the response plus its window size (see Section 2.3).

Tero:

One of the problems here is that if we are using large window size, we have to keep that many messages for ever. It would be nice, we the responder of the request, could forget the response packet after lets say 10 minutes after it sent it out to requestor. There is no reason why the other end should be allowed to resend his request 4 hours later and expect that other end can still resend reply back. So suggest adding:

Responder are allowed to forget response after long timeout for the memory saving purposes. The timeout must be longer than several minutes that could be used for the retransmission timers of the other end.

Paul: Not done. This is a change to the protocol. The WG might want it, but it will have to be an explicit decision from the WG.
Yaron: I support Tero's proposal. Although strictly speaking this is changing the protocol, it can be seen as a reasonable clarification.

Email secured by Check Point

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Wed, 28 Jan 2009 10:38:41 +0200

Yaron Sheffer wrote:

>   For every pair of IKE messages, the initiator is responsible for
>   retransmission in the event of a timeout. The responder MUST never
>   retransmit a response unless it receives a retransmission of the
>   request. In that event, the responder MUST ignore the retransmitted
>   request except insofar as it triggers a retransmission of the
>   response. The initiator MUST remember each request until it receives
>   the corresponding response. The responder MUST remember each
>   response until it receives a request whose sequence number is larger
>   than or equal to the sequence number in the response plus its window
>   size (see Section 2.3).
> Tero:
> One of the problems here is that if we are using large window size, we have to keep that many
> messages for ever. It would be nice, we the responder of the request, could forget the response
> packet after lets say 10 minutes after it sent it out to requestor. There is no reason why the
> other end should be allowed to resend his request 4 hours later and expect that other end can still
> resend reply back. So suggest adding:
>
> Responder are allowed to forget response after long timeout for the memory saving purposes. The
> timeout must be longer than several minutes that could be used for the retransmission timers of the
> other end.
>

I'm not sure about this. Supporting a large window size is only necessary if there are a lot of concurrent exchanges. In that case, the responses expire from the cache before the 10 minutes (or one) are up.

On the other hand, even with a window size of 1, the current text seems to suggest that the last packet should be retained indefinitely. This doesn't make sense, as the initiator of that packet is also bound by the "at least a dozen times over a period of at least several minutes", so four hours later, the initiator has either given up on the IKE SA, or has received the response.

So I'm with Tero on this one.