Subject: [Hipsec] ICMP vs. NOTIFY

From: [email-masked] (Henderson, Thomas R)
Date: Sat Apr 24 13:34:01 2004

> -----Original Message-----
> From: Petri Jokela [mailto:[email-masked]]
> Sent: Tuesday, April 20, 2004 11:54 PM
> To: [email-masked]
> Subject: [Hipsec] ICMP vs. NOTIFY
>=20
>=20
> "
> If the host's policy does not permit it to enter into a HIP
> exchange with the Initiator, it should send an ICMP
> 'Destination Unreachable, Administratively Prohibited'
> message or a NOTIFY packet with "BLOCKED_BY_POLICY" error type.
> One must note that a HIP packet may open more potential DoS
> attacks than a simple ICMP message.
> "
>=20
>
I think that is a good suggestion.  It may be that the HIP NOTIFY
is most useful in less critical situations but that ICMP might be=20
favored in a more hardened system.

Tom=20

---

From: [email-masked] (Pekka Nikander)
Date: Tue Apr 27 03:26:01 2004

> is most useful in less critical situations but that ICMP might be

I agree.  However, I am somewhat worried about replying to I1
packets with anything else but with R1 or ICMP.

For reasons that I can't really spell out (and hence don't
really count), I don't like the NOTIFY much.  I think it may
be fine when you reply to an I2 that has already been partially
verified, but responding to an I1 seems risky.

Personally, I would like to remove some of the error types,
and make same kind of functionality in ICMP level.  The ones
that I would like to weed are the following:

INVALID_MAJOR_VERSION
INVALID_COOKIE_SOLUTION

What comes to the rest, I would specify that a Responder sends
a NOTIFY only if it has successfully validated the puzzle solution.
In response to I1 or to an I2 with an invalid puzzle solution,
the Responder would reply with an ICMP.

In some early version of the draft (or the architecture draft)
there was lengthy discussion why NOTIFY is not very usable, and
why it is better to send ICMP or just let the Initiator retry
after timeout.  While that discussion may still appear somewhere
(I didn't check for this message) and while it is mostly true
from a pure security point of view, it definitely makes debugging
and some operational matters hard.  Hence, NOTIFY after a good
puzzle solution seems like a good compromise, to me.

If others agree, the next question is then about ICMP error types.

In the IPv6 world, we could use Parameter Problem (Type 4), Code 0
(erroneous header field encountered) for INVALID_MAJOR_VERSION,
by making the pointer to point to the HIP version number in the
HIP header.

INVALID_COOKIE_SOLUTION can be handled in the same way.  There
we just set the pointer to point to the puzzle solution field in
the SOLUTION parameter.

In the IPv4 world, the situation is harder.  Parameter Problem
(Type 12) could still be used, but 64 bits (8 bytes) of the original
datagram are not sufficient for INVALID_COOKIE_SOLUTION; it does
suffice for INVALID_MAJOR_VERSION, though.

An idea:  What if we define a new control, INVALID_COOKIE_SOLUTION?
The Controls field still fits within the 64 bits returned in ICMPv4.
In that way the ICMP message could contain the first 8 bytes of the
original HIP message (actually more to include the HITs), and the
control would indicate that the packet was dropped because the
cookie solution didn't verify.

Thoughts?

--Pekka