Re: issue 11 -- window size

Mohan Parthasarathy writes:
> This is an important point. The IKEv2 draft says:
> 
>    An IKE endpoint MUST keep a copy of (or be
>    able to regenerate exactly) the number of previous responses equal to
>    its declared window size in case its response was lost and the
>    initiator requests its retransmission by retransmitting the request.

This is different case. This is for the responses send based on the
request. 

>  It is hard to regenerate an exact copy without storing and hence
> implementations store the packet i guess. We want to honor that here
> i guess. Otherwise, the retransmitted message can change from the
> first time.

There are two cases there.

1) How to check that the request is same.
2) How to retransmit the response if retransmission of request is
found.

For 1) simply checking the message ID would be enough, but as people
do consider that somewhat bad to retransmit packet so easily, they
will store the hash of the request packet and use that to verify that
the retransmission is really a retransmission, not some random garbage
from net.

For 2) implementations need to store the response packet they are
sending back, or at least store enough information that they can
regenerate the previous packet exactly.

> It depends on what you mean by working with NATs. If i move behind a NAT
> (where there was no NAT previously), and want to detect NAT, Prevent NAT etc.
> you want MOBIKE to work in these cases.
> 
> In a previous discussion on this mailing list, at least some of us
> felt that it should work with NAT and taking addresses from the IP
> header should not be the only way to do it.

If you want it to work with NATs, your only option is to take
addresses from IP header. You can store information inside the packet
also to do detection of NAT, but you cannot really use that
information inside the packet for anything else than NAT detection.
-- 
[email protected]