Re: issue 11 -- window size

 > > >
> > The receiver needs to do a HASH to detect the change.
> > Today the receiver on receiving the above message, just
> >  sends the stored response out as he knows it is a retransmission
> >  by just looking at the Message-id. 
> 
> You could do it also based only on the message-ids, but then you do
> not notice if the other end is acting incorrectly (i.e. the packet
> changes) etc. You also open reflection attack, as attacker need to
> simply guess the message-id in use to be able to trig you to send
> retransmission to forged addresses. If you do the hash, then attacker
> must have also been seen the original packet too. Calculating and
> storing the hash is already done by some implementations of IKEv2
> (without mobike), just to protect agains those attacks, and as that is
> how people do it in IKEv2, I used the same explination for the mobike.
> 
Ok, thanks for the clarification.

> The protocol does not require to do the hash, it works perfectly
> without that too, but as there is implementations out there who do
> calculate the hash (or store the whole packet), you cannot change the
> packet after you have first time sent it. You can change the IP and

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.

 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.

<snip>

> 
> > Hence NAT-D need not be included in every
> > message i guess.
> 
> That depends what we do for the NAT-T and MOBIKE. If we want MOBIKE to
> work with NATs, we need to take IP-addresses from outer IP-header
> anyways, so we do not necessary need any NAT-D packets.
> 
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. 

> > Perhaps, there might be something else in the
> > future. Even if we move the PATH_TEST message outside
> > the normal window, we might still have to potentially retransmit
> > the pending message with new address (as described here)
> > and hence the new processing from the receiver is still required.
> 
> Yes, we might need the same processing anyways, so my suggestion was
> that one option could be to simply use it always, thus there would not
> be need for the separate PATH_TEST message.

Okay.

-mohan

> -- 
> [email protected]