Re: issue 11 -- window size

Mohan Parthasarathy writes:
> > Host B gets retramission of 57, he verifies that it is
> > retranmission by checking the HASH(DPD), and because
> > it matches, he sends stored copy of message id 57R
> > back, without doing any more processing for the
> >
> 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.

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
port, but you cannot add any payloads etc to it. IP and port are not
included in the HASH as the IKEv2 draft says you need to respond even
to the retransmission coming from different IP and port.

Actually for the authenticated packets, it is enough to store the MAC
of the packet...

> > packet (i.e. he does not run any IKE state machines to
> > process the packet). 
> > 
> > (drop) <- (B1, A2, 57R) DPD reply
> > 
> > Host A moves to next address and retransmits
> > 
> > (A3, B1, 57) DPD ->
> > 
> > Host B again notices about retranmission, and replies
> > with his stored packet.
> > 
> When the host detects the HASH change, he notes down
> *just* the new addresses so that the response can be
> sent to the new place.

Responder does not detecth HASH change, as it does not change. The
HASH is calculated over the IKE packet, and that does (cannot) not
change. IP address and port are not covered by the hash.

> This implies that the retransmitted
> request from the other end cannot have any changes in the payload
> (except the IP header).

Yes. Retransmission == sending same packet again, so it MUST be
identical to the previous one, as it MUST be ignored by responder, but
MUST trigger retransmission of reply. 

> If any other change is in the payload, 
> then the stored response won't work.

Yes. 

> This might be a bit
> restrictive depending on how the protocol evolves.

This how it is done in the IKEv2, and I do not think we should be
changing it in the MOBIKE. 

> So, the main advantage and difference of moving the PATH_TEST
> message outside the normal window processing is that it can be a
> totally new message.

That is one option. I just explained another option, which does not
require it to be outside the normal window processing.

> 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.

> 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.
-- 
[email protected]