Subject: [Hipsec] Base HIP: new issues

From: [email-masked] (Petri Jokela)
Date: Tue May 11 03:07:00 2004

I added some new issues to the tracker:

Issue tracker:
http://hip4inter.net/cgi-bin/roundup.cgi/hip-base/index

Issue #35: ICMP error type to be used for errors that occur before the
cookie has been solved.

Issue #36: UPDATE message handling (8.11.) needs some work.

Issue #37:  the usage of the "Notification data" -field is not clearly
defined for the NOTIFY parameter.

Issue #38: Size of K in PUZZLE and the Opaque field.

Shall we maintain the Opaque field in the PUZZLE/SOLUTION or should we
use only ECHO REQUEST/REPLY for this purpose? And what to do with the K
that is currently 8 bits in front of the Opaque field: is 8 bits enough,
or shall we allocate more space for it?

K and Opaque should probably be two different issues, but they are
fighting for the same space in the parameter, so that's why I put
them under the same issue.

Any comments/proposals?

/petri

---

From: [email-masked] (Pekka Nikander)
Date: Wed May 12 06:27:00 2004

> Issue #35: ICMP error type to be used for errors that occur before the

Here is a text proposal, based on my earlier comments.

--Pekka

-----------------------------------------------------------
New subsection (4.3?) to Section 4:

<section title="Error processing">
   <t>HIP error processing behaviour depends on whether there
   exists an active HIP association or not.  In general, if an HIP
   security association exists between the sender and receiver of a
   packet causing an error condition, the receiver SHOULD respond
   with a NOTIFY packet.  On the other hand, if there are no
   existing HIP security associations between the sender and receiver,
   or the receiver
   cannot reasonably determine the identity of the sender, the
   receiver MAY respond with a suitable ICMP message; see
   <xref target="ICMP" /> for more details.</t>
</section>

-----------------------------------------------------------
A change to Section 5.1, HIP Scenarios:

Old text:
>          The receiver 'detects' the situation when it receives an ESP
>          packet that contains an unknown SPI. The receiving host MAY
>          send a NOTIFY packet with NOTIFY parameter informing about
>          invalid SPI or it MAY initiate a new HIP negotiation.  
> However,
>          managing such situations is implementation dependent.
New text:
           <t>The receiver 'detects' the situation when it receives
           an packet that contains an unknown SPI.  The receiving host
           MAY send an ICMP packet with the Parameter Problem type to
           inform about invalid SPI (see <xref target="ICMP" />,
           and it MAY initiate a new HIP negotiation.  However,
           managing such situations is implementation dependent.</t>

-----------------------------------------------------------
A change to Section 5.3:

Old text:
>    If a system receives an ESP packet for an unknown SPI, it is 
> possible
>    that it has lost the state and its peer has not.  It MAY send a
>    NOTIFY packet with INVALID_SPI error type. Reacting to ESP traffic
>    with unknown SPI depends on the implementation and the environment
>    where the implementation is used.
New text:
     <t>If a system receives an ESP packet for an unknown SPI, it is 
possible
     that it has lost the state and its peer has not.  It MAY send an
     ICMP packet with the Parameter Problem type, the Pointer pointing to
     the SPI value within the ESP header.  Reacting to ESP traffic
     with unknown SPI depends on the implementation and the environment
     where the implementation is used.</t>

-----------------------------------------------------------
Changes to Section 5.4.2:

Old text:
>    Receive ESP for unknown SA, send NOTIFY with INVALID_SPI parameter 
> and
>      stay at UNASSOCIATED
New text:
     Receive ESP for unknown SA, optionally send ICMP as defined
     in <xref target="ICMP" /> and stay at UNASSOCIATED

-----------------------------------------------------------
Changes to Section 6.2.18 (NOTIFY):
- remove Error Type 5, INVALID_MAJOR_VERSION
- remove Error Type 11, INVALID_SPI
- remove Error Type 30, INVALID_COOKIE_SOLUTION

-----------------------------------------------------------
New subsection (6.3) to Section 6:

<section anchor="ICMP" title="ICMP messages">
   <t>When a HIP implementation detects a problem with an incoming
   packet, and it either cannot determine the identity of the sender
   of the packet or does not have any existing HIP security association
   with the sender of the packet, it MAY respond with an ICMP packet.
   Any such replies MUST be rate limited as described in
   <xref target="RFC1885" />.  In most cases, the ICMP packet will
   have the Parameter Problem type (12 for ICMPv4, 4 for ICMPv6), with
   the Pointer field pointing to the field that caused the ICMP message
   to be generated.</t>

   <t>XXX: Should we say something more about rate limitation here?</t>

   <section title="Invalid Version">

     <t>If a HIP implementation receives a HIP packet that has
     an unrecognized HIP version number, it SHOULD respond, rate
     limited, with an ICMP packet with type Parameter Problem, the
     Pointer pointing to the VER./RES. byte in the HIP header.</t>

   </section>

   <section title="Other problems with the HIP header and packet 
structure">

     <t>If a HIP implementation receives a HIP packet that has
     other unrecoverable problems in the header or packet format,
     it MAY respond, rate limited, with an ICMP packet with type
     Parameter Problem, the Pointer pointing to the field that
     failed to pass the format checks.  However, an implementation
     MUST NOT send an ICMP message if the Checksum fails; instead,
     it MUST silently drop the packet.</t>

   </section>

   <section anchor="uSPI" title="Unknown SPI">

     <t>If a HIP implementation receives an ESP packet that has
     an unrecognized SPI number, it MAY responder, rate limited,
     with an ICMP packet with type Parameter Problem, the Pointer
     pointing to the the beginning of SPI field in the ESP header.</t>

   </section>

   <section title="Invalid Cookie Solution">

     <t>If a HIP implementation receives an I2 packet that has
     an invalid cookie solution, the behaviour depends on the
     underlying version of IP.  If IPv6 is used, the implementation
     SHOULD respond with an ICMP packet with type Parameter
     Problem, the Pointer pointing to the beginning of the
     Puzzle solution #J field in the SOLUTION payload in the HIP
     message.</t>

     <t>If IPv4 is used, the implementation MAY respond with
     an ICMP packet with the type Parameter Problem, copying
     enough of bytes form the I2 message so that the SOLUTION
     parameter fits in to the ICMP message, the Pointer pointing to
     the beginning of the Puzzle solution #J field, as in the IPv6
     case.  Note, however, that the resulting ICMPv4 message exceeds
     the typical ICMPv4 message size as defined in
     <xref target="RFC792" />.</t>

   </section>

</section>

-----------------------------------------------------------
Change to Section 8.2 Processing incoming application data

Old text:
>    1.  Detect the proper IPsec SA using the SPI.  If the resulting SA 
> is
>        a non-HIP ESP SA, process the packet according to standard IPsec
>        rules.  If there are no SAs identified with the SPI, the host 
> MAY
>        send a NOTIFY packet with error type INVALID_SPI.  How to handle
>        lost state is an implementation issue.
New text:
     <t>Detect the proper IPsec SA using the SPI.  If the resulting SA is
        a non-HIP ESP SA, process the packet according to standard IPsec
        rules.  If there are no SAs identified with the SPI, the host MAY
        send an ICMP packet as defined in <xref target="uSPI" />.  How to
        handle lost state is an implementation issue.</t>

-----------------------------------------------------------
New subsection 8.5.2 to Section 8.5:

<section title="Handling malformed messages">
   <t>If an implementation receives a malformed I1 message, it
   SHOULD NOT respond with a NOTIFY message, as such practice could
   open up a potential denial-of-service danger.  Instead, it
   MAY respond with an ICMP packet, as defined in <xref target="ICMP" 
/>.</t>
</section>

-----------------------------------------------------------
New subsection 8.6.1 to Section 8.6:

<section title="Handling malformed messages">
   <t>If an implementation receives a malformed R1 message, it
   MUST silently drop the packet.  Sending a NOTIFY or ICMP would
   not help, as the sender of the R1 typically doesn't have any
   state.  An implementation SHOULD wait for some more time for a
   possible good R1, after which it MAY try again by sending a new
   I1 packet.</t>
</section>

-----------------------------------------------------------
New subsection 8.7.1 to Section 8.7:

<section title="Handling malformed messages">
   <t>If an implementation receives a malformed I2 message,
   the behaviour SHOULD depend on how much checks the message
   has already passed.  If the puzzle solution in the message
   has already been checked, the implementation SHOULD report
   the error by responding with a NOTIFY packet.  Otherwise
   the implementation MAY respond with an ICMP message as defined
   in <xref target="ICMP">.</t>
</section>

-----------------------------------------------------------
I don't think that Sections 8.8 or 8.11-8.15 need anything
specific.

Should there be a generic subsection in 8., maybe 8.16, that
defines the general rules?  I think not, as they are defined
in the new Section 6.3.

---

From: [email-masked] (Kristian Slavov)
Date: Wed May 12 06:47:01 2004

> Issue #35: ICMP error type to be used for errors that occur before the

What are those errors? I can think of  SRC/DST HITs being wrong, peer's HOST_ID 
not matching with its HIT, a wrong solution to the puzzle/unable to solve the 
puzzle and generally invalid I1/R1/I2.

Wrong HITs in HIP header should probably lead to silent discard of the packet, 
or an ordinary ICMP destination unreachable message.

If peer's HOST_ID in R1 is different from peer's HIT, then I guess we should 
drop the R1 and possibly send another I1. I don't think it is rational to send 
an ICMP message to the responder and "demand" it to fix its HOST_ID TLV and 
calculate new signature(s).

Wrong solution to the puzzle could be notified, although I think every 
implementation SHOULD know whether or not it solved the puzzle (or else the 
implementation doesn't work).

If the initiator is unable to solve the puzzle, it could request another R1 by 
resending I1. There is no need for ICMP error message here.

For general problems in I1/R1/I2, we could use ICMP Parameter Problem message.
Botrh ICMP and ICMPv6 seem to support it. The pointer field in the ICMP PP 
message could be the offset to the start of the offending TLV. [RFC792, RFC2463]

There is a problem, however, that since the ICMP packet does not carry the whole
HIP packet, the offsets do not necessarily point to the problem TLV. Especially 
if there are optional and variable length TLVs.

-- 
Kristian Slavov, Researcher
Helsinki Institute for Information Technology
Gsm: +358-40-7220960