Subject: [Hipsec] Issue 23: New substate to handle ICMP attacks

From: [email-masked] (Pekka Nikander)
Date: Wed Oct 8 10:38:01 2003

As a part of his arch doc review, Tom Henderson writes:

> - in reading Section 9, it reminded me that we probably want yet
> another state to linger after ICMP messages (wait for a while to see
> if legitimate R1 comes in before dropping back to E0).

In my opinion, we most probably do not want to complicate the
conceptual state machine with such an additional state.  (The
implementations are free to add such a state, of course).  Instead, I 
suggest that we add a new section before the current Section 8.5, 
Processing incoming R1 packets.

Here is a proposal for the text:

       <section title="Processing incoming ICMP Protocol Unreachable
         messages">

	<t>A host may receive an ICMP Destination Protocol Unreachable
	message as a response to sending an HIP I1 packet.  Such a
	packet may be an indication that the peer does not support
	HIP, or it may be an attempt to launch an attack by making the
	Initiator to believe that the Responder does not support
	HIP.</t>

	<t>When a system receives an ICMP Destination Protocol
	Unreachable message while it is waiting for an R1, it MUST NOT
	terminate the wait.  It MAY continue as if it had not received
	the ICMP message, and send a few more I1s.  Alternatively, it
	MAY take the ICMP message as a hint that the peer most
	probably does not support HIP, and return to state E0 earlier
	than otherwise.  However, at minimum, it MUST continue waiting
	for an R1 for a reasonable time before returning to E0.</t>

       </section>

Is this OK?

--Pekka Nikander

---

From: [email-masked] (Mika Kousa)
Date: Wed Oct 8 11:30:02 2003

On Wed, 8 Oct 2003, Pekka Nikander wrote:

-> Here is a proposal for the text:
->
->        <section title="Processing incoming ICMP Protocol Unreachable
->          messages">
->
-> ....
->
-> 	<t>When a system receives an ICMP Destination Protocol
-> 	Unreachable message while it is waiting for an R1, it MUST NOT
-> 	terminate the wait.  It MAY continue as if it had not received
-> 	the ICMP message, and send a few more I1s.  Alternatively, it
-> 	MAY take the ICMP message as a hint that the peer most
-> 	probably does not support HIP, and return to state E0 earlier
-> 	than otherwise.  However, at minimum, it MUST continue waiting
-> 	for an R1 for a reasonable time before returning to E0.</t>
->
->        </section>
->
-> Is this OK?

Looks good to me. I think we need not to define the exact maximum waiting
time in the text because the needed waiting time depends on many issues
such as RTT and such. So, the interpretation of "a reasonable time" can be
left implementation specific.