Subject: [Hipsec] HIP Notify text

From: [email-masked] (Henderson, Thomas R)
Date: Sun Mar 21 15:55:01 2004

Below is some candidate text to deal with the HIP Reject issue
discussed at the IETF-59 meeting.  It is based the Notify Payload
of the IKEv2 draft.  

I defined both a new NOTIFY parameter and a NOTIFY packet.  The text
below states that NOTIFY packet is optional.  The text also 
states that the NOTIFY parameter is only sent in a NOTIFY packet, 
although it may be possible to send NOTIFY parameters in other
packets in the future (e.g., perhaps an R2 in the future does not
contain the normal parameters but instead a NOTIFY parameter that
indicates why the I2 failed processing).  However, I refrained from 
defining that for now, to err on the side of simplicity.

The NOTIFY parameter type code and NOTIFY packet type code are 
undefined in the below text-- I do not know the convention for these
assignments (Petri can fill in).  The Notify Message Type codes are 
based on similar codes in IKEv2, but there is not a 1-to-1 mapping.

Note also that a mechanism for sending a packet to indicate
Unknown SPI is included.

6.2 HIP parameters

      TLV               Type  Length     Data

      NOTIFY		XX    variable   Informational data

6.2.14 NOTIFY

  The NOTIFY parameter is used to transmit informational data, such as
  error conditions and state transitions, to a HIP peer.  A NOTIFY
  parameter may appear in the NOTIFY packet type.  The use of the 
  NOTIFY parameter in other packet types is for further study.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Type              |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved            |       Notify Message Type     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      /                        Notification Data                      /
      /                                               +-+-+-+-+-+-+-+-+
      |                                               |    Padding    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type           XX
      Length         length in octets, excluding Type, Length, and Padding
      Reserved       zero when sent, ignored when received
      Notify Message Specifies the type of notification
      Type  
      Notification   Informational or error data transmitted in addition 
      Data           to the Notify Message Type. Values for this field 
                     are type specific (see below).

   Notification information can be error messages specifying why an SA
   could not be established.  It can also be status data that a process
   managing an SA database wishes to communicate with a peer process.
   The table below lists the Notification messages and their
   corresponding values.  

   Types in the range 0 - 16383 are intended for reporting errors.  An
   implementation that receives a NOTIFY error parameter in response to a 
   request packet (e.g., I1, I2, UPDATE), SHOULD assume that the
   corresponding request has failed entirely.  Unrecognized error types
   MUST be ignored except that they SHOULD be logged.

   Notify payloads with status types MUST be ignored if not recognized. 

        NOTIFY PARAMETER - ERROR TYPES           Value
        -----------------------------           -----
        UNSUPPORTED_CRITICAL_PARAMETER_TYPE       1

            Sent if the parameter type has the "critical" bit set and the
            parameter type is not recognized. Notification Data contains
            the two octet parameter type.

        INVALID_MAJOR_VERSION                     5

            Indicates the recipient cannot handle the version of HIP
            specified in the header. The closest version number that the
            recipient can support will be in the reply header.

        INVALID_SYNTAX                            7

            Indicates that the HIP message received was invalid because
            some type, length, or value was out of range or because the
            request was rejected for policy reasons. To avoid a denial
            of service attack using forged messages, this status may
            only be returned for and in an encrypted packet if the
            message ID and cryptographic checksum were valid. To avoid
            leaking information to someone probing a node, this status
            MUST be sent in response to any error not covered by one of
            the other status types. To aid debugging, more detailed
            error information SHOULD be written to a console or log.

        INVALID_SPI                              11

            MAY be sent in a NOTIFY packet when a node receives an ESP 
            packet with an invalid SPI. The Notification Data contains 
            the SPI of the invalid packet.  This usually indicates a node 
            has rebooted and forgotten an SA.  If this Informational Message 
            is sent outside the context of a HIP SA, it should only be used 
            by the recipient as a "hint" that something might be wrong 
            (because it could easily be forged).

        NO_DH_PROPOSAL_CHOSEN                    14

            None of the proposed group IDs was acceptable.

        INVALID_DH_CHOSEN                        15

            The D-H Group ID field does not correspond to one offered
            by the responder.

        NO_HIP_PROPOSAL_CHOSEN                   16

            None of the proposed HIP Transform crypto suites was 
            acceptable.

        INVALID_HIP_TRANSFORM_CHOSEN             17

            The HIP Transform crypto suite does not correspond to 
            one offered by the responder.

        NO_ESP_PROPOSAL_CHOSEN                   18

            None of the proposed ESP Transform crypto suites was 
            acceptable.

        INVALID_ESP_TRANSFORM_CHOSEN             19

            The ESP Transform crypto suite does not correspond to 
            one offered by the responder.

        AUTHENTICATION_FAILED                    24

            Sent in response to a HIP signature failure.

        CHECKSUM_FAILED                          26

            Sent in response to a HIP checksum failure.

        HMAC_FAILED                              28

            Sent in response to a HIP HMAC failure.

        INVALID_COOKIE_SOLUTION                  30

            The responder could not validate the cookie solution.

        ENCRYPTION_FAILED                        32

            The responder could not successfully decrypt the 
            ENCRYPTED TLV.

        INVALID_HIT                              40

            Sent in response to a failure to validate the peer's
            HIT from the corresponding HI.

        NOTIFY MESSAGES - STATUS TYPES           Value
        ------------------------------           -----

        (None defined at present)

7.9 NOTIFY - the HIP Notify Packet

   The NOTIFY packet is OPTIONAL.  The NOTIFY packet MAY be used to
   provide information to a peer.  Typically, NOTIFY is used to
   indicate some type of protocol error or negotiation failure.

   The HIP header values for the NOTIFY packet:

      Header:
        Packet Type = XX
        SRC HIT = Sender's HIT
        DST HIT = Recipient's HIT, or zero if unknown

      IP ( HIP (NOTIFY, HIP_SIGNATURE) )

   Valid control bits: None

   The NOTIFY packet is used to carry a NOTIFY parameter.

8.14 Processing NOTIFY packets

   Processing NOTIFY packets is OPTIONAL.  If processed, any errors 
   noted by the NOTIFY parameter SHOULD be taken into account by the
   HIP state machine (e.g., by terminating a HIP handshake), and the 
   error SHOULD be logged.

---

From: [email-masked] (Miika Komu)
Date: Mon Mar 22 03:49:03 2004

>   NOTIFY parameter in other packet types is for further study.

Good stuff!

Perhaps there should be also a field in the NOTIFY for indicating the
packet header type (I2, R1, UPDATE, etc) for which the NOTIFY packet was
sent as a response?

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

---

From: [email-masked] (Julien Laganier)
Date: Mon Mar 22 06:03:01 2004

On Monday 22 March 2004 10:34, Miika Komu wrote:
> >   The NOTIFY parameter is used to transmit informational data,
> > such as error conditions and state transitions, to a HIP peer.  A
> > NOTIFY parameter may appear in the NOTIFY packet type.  The use
> > of the NOTIFY parameter in other packet types is for further
> > study.
> >
> >        0                   1                   2                 
> >  3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
> > 1
> >       |             Type              |             Length       
> >       |           Reserved            |       Notify Message Type
> >       |     |
> >
> >      
> >       /                        Notification Data                 
> >     / /                                              
> > +-+-+-+-+-+-+-+-+
> >       |                                               |    Padding    
|
> >       Length         length in octets, excluding Type, Length,
> > and Padding Reserved       zero when sent, ignored when received
> >       Notification   Informational or error data transmitted in
> > addition Data           to the Notify Message Type. Values for
> > this field are type specific (see below).
>
> Good stuff!
>
> Perhaps there should be also a field in the NOTIFY for indicating
> the packet header type (I2, R1, UPDATE, etc) for which the NOTIFY
> packet was sent as a response?

But an implementation receiving a NOTIFY packet knows what packets it 
send before, right? I fail to see the need...

OTOH, it would certainly be useful to be able to notify several error 
types within different parameters... One could achieve this by 
replacing the 

{ Reserved (16 bit) | Notify Message Type (16 bit) | Notification 
data } 

proposed by Thomas by several Notify chunks:

{ Notify Parameter Type (16 bit) | Notify Parameter Type (16 bit)
| Notification Data }

The Parameter Type being set to the parameter type which triggered 
this notify (e.g., SPI, COOKIE, DH, etc.), or 0 if it's caused by the 
base HIP header, and the Notify Parameter sub-type being a per 
parameter defined sub type. For example, the parameter SPI could have 
the following notify subtypes:

o UNKNOWN_SPI 0x01
o ALREADY_USED_SPI 0x02
o EXPIRED_SPI 0x03

IMHO it gives much more flexibility in notifying errors while not 
being overly complex...

Thoughts? Thanks,

--julien

---

From: [email-masked] (Miika Komu)
Date: Mon Mar 22 08:12:01 2004

> send before, right? I fail to see the need...

You are probably right... even if there would be this new field, it would
have to be double checked from the state machine.

---

From: [email-masked] (Mika Kousa)
Date: Tue Mar 23 04:14:00 2004

->         NOTIFY PARAMETER - ERROR TYPES           Value
->         -----------------------------           -----
-> ...
->         INVALID_HIT                              40
->
->             Sent in response to a failure to validate the peer's
->             HIT from the corresponding HI.

And "opportunistic mode not supported" if responder HIT is NULL ?

-> 7.9 NOTIFY - the HIP Notify Packet
->
->    The NOTIFY packet is OPTIONAL.  The NOTIFY packet MAY be used to
->    provide information to a peer.  Typically, NOTIFY is used to
->    indicate some type of protocol error or negotiation failure.
->
->    The HIP header values for the NOTIFY packet:
->
->       Header:
->         Packet Type = XX
->         SRC HIT = Sender's HIT
->         DST HIT = Recipient's HIT, or zero if unknown
->
->       IP ( HIP (NOTIFY, HIP_SIGNATURE) )
->
->    Valid control bits: None
->
->    The NOTIFY packet is used to carry a NOTIFY parameter.

Would it be useful if NOTIFY packet could contain multiple NOTIFY
parameters (eg. to indicate multiple errors in one packet) ?

---

From: [email-masked] (Mika Kousa)
Date: Tue Mar 23 04:49:04 2004

-> On Monday 22 March 2004 10:34, Miika Komu wrote:
-> >
-> > Perhaps there should be also a field in the NOTIFY for indicating
-> > the packet header type (I2, R1, UPDATE, etc) for which the NOTIFY
-> > packet was sent as a response?
->
-> But an implementation receiving a NOTIFY packet knows what packets it
-> send before, right? I fail to see the need...

There might be some need.

Let's say that two hosts send eg. several UPDATE packets really fast (not
a likely scenario but anyway). The other host notices an error in the
first UPDATE packet and sends a NOTIFY packet related to this failed
UPDATE packet. Then the NOTIFY packet gets stuck somewhere in-between the
hosts, but new UPDATE packets keep coming through before the NOTIFY packet
is finally received. Now, how can you differentiate which UPDATE of the
several received ones contained errors ?

-> OTOH, it would certainly be useful to be able to notify several error
-> types within different parameters... One could achieve this by
-> replacing the
->
-> { Reserved (16 bit) | Notify Message Type (16 bit) | Notification
-> data }
->
-> proposed by Thomas by several Notify chunks:
->
-> { Notify Parameter Type (16 bit) | Notify Parameter Type (16 bit)
-> | Notification Data }

Sounds like a good idea to me, too.

---

From: [email-masked] (Petri Jokela)
Date: Tue Mar 23 07:32:01 2004

> discussed at the IETF-59 meeting.  It is based the Notify Payload

Good text, I will edit this into draft and we'll see how it looks like.

> based on similar codes in IKEv2, but there is not a 1-to-1 mapping.

With the parameter type, we control its place relative to other 
parameters. In case of NOTIFY packet, we just put it before the 
HIP_SIGNATURE, with smaller type value. If we do not define the NOTIFY 
parameter to be used in other packets, the value doesn't matter so much. 
But, if we look into future, are there currently existing parameters 
that would require the NOTIFY to be after or before them?

/petri

-- 
Petri Jokela                        Tel:    +358 9 299 2413
Research scientist                  Fax:    +358 9 299 3535
NomadicLab, Ericsson Research       Mobile: +358 44 299 2413
Oy L M Ericsson Ab                  email: [email-masked]

---

From: [email-masked] (Petri Jokela)
Date: Tue Mar 23 07:36:01 2004

> packet header type (I2, R1, UPDATE, etc) for which the NOTIFY packet was

Maybe the Notification Data part should contain some information related 
to the rejected packet? Header of the rejected packet maybe?

/petri

---

From: [email-masked] (Mika Kousa)
Date: Tue Mar 23 08:08:01 2004

I might have misunderstood something, but I need some clarifications while
I'm trying to implement the UPDATE packet:

Example scenario:

After the base exchange, host A increments outgoing UPDATE ID counter from
value 0 to 1 and sends UPDATE packet to B. Now host B has stored A's
incoming UPDATE ID value 1. B responds with corresponding UPDATE packet
(with UPDATE ID 1) and host A stores B's incoming UPDATE ID value 1. Both
hosts are also again in established state. Then the same process is done
again, so the result is that B has stored A's incoming UPDATE ID value 2
and host A has stored B's incoming UPDATE ID value 2. Nothing unclear so
far, because I understood that incoming UPDATE IDs are recorded regardless
whether the packet is a reply or not (at least draft-09 section 8.10
(Processing UPDATE packets) bulletin point 7. does not differentiate the
cases).

Then host B sends UPDATE with (its own outgoing) ID 1 to host A. B moves
now to rekeying state. When host A receives the UPDATE packet it starts to
handle the packet according to draft-09 section 8.10:

"1. If the system is in state ESTABLISHED and the UPDATE has the R-bit set
in the NES TLV, the packet is silently dropped.". This is not true,
because the R-bit is not set.

"2. If the UPDATE ID in the received UPDATE is smaller than the stored
incoming UPDATE ID, the packet MUST BE dropped."

Host A sees that incoming ID value in the reply UPDATE is 1. Also, A sees
that the last incoming ID received before from host B was 2, so this reply
packet is dropped. Assuming that the implementation follows strictly the
steps defined in the draft, this causes problems.

Therefore, should section 8.10 bulletin point 2. say "If the UPDATE does
not have the R-bit set and the UPDATE ID in the received UPDATE is smaller
than the stored incoming UPDATE ID, the packet MUST BE dropped" instead of
the current text "If the UPDATE ID in the received UPDATE is smaller than
the stored incoming UPDATE ID, the packet MUST BE dropped" ?

---

From: [email-masked] (Jan Mikael Melen)
Date: Wed Mar 24 09:35:02 2004

I don't quite follow your concept of incoming and outgoing update IDs but here 
is how I have understood it.

When B receives first update  from A. B records the value (1) and replys with 
update ID 1. When B receives second update ID it compares that the received 
value in update is greater than in the previous update packet and if so 
replies with the new value.

Now when A receives first update from B. A records the value (1). A replies 
with update ID 1. And yet same again as above (2<->2)...

So one should have two values in both ends
my_update_id
peer_update_id

my_update_id tells you the ID which you have sent last in UPDATE (not in 
reply). This should be incremented before sending UPDATE and include this 
incremented value in to UPDATE packet. When receiving a reply, one should 
check that the value is same in the reply packet as stored in to this 
variable.

peer_update_id tells you the ID which you have received last in UPDATE (not 
reply). When receiving UPDATE, one should check that the value in received 
UPDATE ID is greater or same. Store the received value in to this variable. 
Make a reply packet and include this value in to the reply packet.

In simplified pseudo-code:
send_update () {
     updateID = ++my_update_id;
     send_update_packet (updateID);
}

receive_update_reply () {
      updateID = parse_updateID();
      if ( updateID == my_update_id ) then
           update_reply_ok_now_update_sa();
     else
	   discard_update_reply();
    fi
}

receive_update ()  {
      updateID = parse_updateID();
      if (updateID >= peer_update_id) then 
	   peer_update_id = updateID;
           send_update_reply_packet (peer_update_id);
	   prepare_sa_wait_for_data();
     else
	   discard_update();
    fi
}

I hope this helps!

  Regards,
	Jan

On Tuesday 23 March 2004 15:53, Mika Kousa wrote:
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: [email-masked] (Jonathan Wood)
Date: Thu Mar 25 01:20:01 2004

I agree with Jan's explanation below.

However, I also think that the draft is less clear than it could be
about how to handle update IDs - perhaps Jan's text could
be adapted into a section explicitly addressing update IDs?

Also, the draft needs to specify how to handle resetting
update ID counters after a resync (if it's in the draft, I must
have missed it...). Resetting both peer_update_id and
my_update_id to zero should do the trick.

Jon

On Mar 24, 2004, at 7:21 AM, Jan Mikael Melen wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>

---

From: [email-masked] (Mika Kousa)
Date: Thu Mar 25 06:07:01 2004

On Wed, 24 Mar 2004, Jan Mikael Melen wrote:

-> So one should have two values in both ends
-> my_update_id
-> peer_update_id
->
-> ...
->
-> peer_update_id tells you the ID which you have received last in UPDATE (not
-> reply). When receiving UPDATE, one should check that the value in received
-> UPDATE ID is greater or same.

Yes, I understood your answer, but this issue of storing incoming/outgoing
UPDATE IDs is one of the things I needed clarifications on. Draft section
8.10 bulletin point 7 says that "The system MUST record the UPDATE ID in
the received packet, for replay protection.". Note that this does not say
anything about if we must care about the R-bit when storing the
peer_update_id. When I was implementing UPDATE packet I just blindly
followed the draft, and then ran into some problems when packets were
dropped.

It would be nice if the draft section 8.10 bulletin point 7 would
explicitly say that the incoming UPDATE ID is stored only if the packet is
not a reply.

---

From: [email-masked] (Petri Jokela)
Date: Thu Mar 25 06:47:01 2004

> be adapted into a section explicitly addressing update IDs?

in 8.10, bullet 7, changing a bit:

7. The system MUST record the UPDATE ID in the received initial UPDATE 
packet, for replay protection.

This should remove the possibility to misunderstand the process.

One thing that 8.10 does not say anything about: UPDATE reply packets 
that have an UPDATE ID that does not match to any sent initial UPDATE 
packet (or have I missed this somewhere). This reply packet is, of 
course, dropped. But should it be said in 8.10., e.g. after bullet 1:

2. If the system is in state REKEYING, the UPDATE has the R-bit set, but 
the UPDATE ID does not match any sent initial UPDATE packet, the packet 
is silently dropped.

> my_update_id to zero should do the trick.

This will go into resync-draft, if the resync-process is decided to be 
removed from the base draft. Otherwise, it shall be done here.

/petri