Subject: [Hipsec] packet processing text

From: [email-masked] (Henderson, Thomas R)
Date: Thu Sep 4 18:12:00 2003

Pekka,
Here is some draft text that is a start to section 8 material.
Embedded in the text are some notes and questions that may
generate some more discussion.  Feel free to further edit.
I did not touch the BOS and CER packet processing.

8. Packet processing

[NOTE1:  This section and section 5.4 could perhaps be combined,
and also the packet processing language in Section 7 could be moved
here.  Section 7 discusses packet processing in the outbound 
direction (how outbound packets should be formatted), while the
below text is more about inbound packet processing.]

[NOTE2:  This draft probably needs a terminology section that 
defines "host" and some other terms.  For example, a host can have 
multiple host identities.  Do we say that HIP daemon talks to a host or 
an identity, when describing state machine operations???.  Do we
even use the term "daemon" (other places it is "implementation"
or "system" or "state machine")?]

[NOTE3:  There is some ambiguity about whether a host may have 
multiple active associations with a given peer host identity.  I am 
assuming that it may, but I noticed some implications on how certain
packets such as R1 are processed in certain states-- perhaps it 
should be discussed and clarified.]

   Each host is assumed to have a HIP daemon that manages the host's
   HIP associations and handles requests for new ones.  Each HIP 
   association is governed by a state machine, with states defined
   above in Section 5.4.  The HIP daemon can simultaneously maintain 
   HIP associations with more than one host.  Furthermore, the
   HIP daemon may have more than one active HIP association with 
   another host; in this case, HIP associations are distinguished by 
   their respective HITs and/or IPsec SPIs. [Q. Is this last possibility 
   true?  Can a host have, or would it want to have, multiple HIP 
   associations (IPsec SAs) with the same peer host identity?]  

   The processing of packets is dependent on the state of the HIP
   association(s) with respect to the authenticated or apparent 
   originator of the packet.  A HIP daemon determines whether it
   has an active association with the originator of the packet based
   on the HITs and/or SPI of the packet.  
   
8.1 Initiation of a HIP exchange
  
   An implementation may originate a HIP exchange to another host based
   on a local policy decision, usually triggered by an application
   datagram, in much the same way that an IPsec key exchange can 
   dynamically create a Security Association (SA).  In such a case, 
   the implementation prepares an I1 packet and sends it to the IP 
   address that corresponds to the peer host.  The IP address of the 
   peer host may be obtained via conventional mechanisms such as DNS 
   lookup.  The I1 contents are specified in Section 7.1.  The selection 
   of which host identity to use, if a host has more than one to choose 
   from, can also be a policy decision.  

   The Initiator gets the Responder's HIT either from a DNS lookup of
   the responder's FQDN, from some other repository, or from a local
   table.  If the initiator does not know the responder's HIT, it may
   attempt anonymous mode by using NULL (all zeros) as the responder's
   HIT.

   Alternatively, a system may initiate a HIP exchange if it has 
   rebooted or timed out, or otherwise lost its HIP state, as described
   in Section 5.3.

   Upon sending an I1, the sender shall transition to state E1 and
   start a timer whose timeout value should be larger than the worst-case 
   anticipated RTT, and shall increment a timeout counter associated with 
   the I1.  The sender SHOULD retransmit the I1 upon a timeout and restart 
   the timer, up to a maximum of N1 tries.

8.2 Processing I1 packets

   An implementation SHOULD reply to an I1 with an R1 packet, unless 
   the implementation is unable or unwilling to setup a HIP association.
   If the implementation is unable to setup a HIP association, the
   host SHOULD send an ICMP Destination Protocol Unreachable message
   to the I1 source address.  If the implementation is unwilling to
   setup a HIP association, the host MAY ignore the I1.  This latter
   case may occur during a DoS attack such as an I1 flood.

   If the implementation chooses to respond to the I1 with an R1 packet,
   it should create or select a precomputed R1 according to the
   format described in Section 7.2 and send the R1 to the source IP
   address of the I1 packet.  Under no circumstances does the HIP state
   machine transition upon sending an R1.  

   The implementation MUST be able to handle a storm of received I1 
   packets, discarding those with common content that arrive within a 
   small time delta.

   The HIP control bits MUST be ignored in the received I1.  The received
   Initiator HIT MUST be copied over to the Initiator HIT field in the R1.
   The transmitted R1 is formatted as specified in Section 7.2.

8.2.1 R1 Management

   All compliant implementations MUST produce R1 packets. An R1 packet
   MAY be precomputed. An R1 packet MAY be reused for time Delta T. R1
   information MUST not be discarded until Delta S after T.  Time S is
   the delay needed for the last I2 to arrive back to the responder. A
   spoofed I1 can result in an R1 attack on a system.  An R1 sender MUST
   have a mechanism to rate limit R1s to an address.

   An implementation MAY keep state about received I1s and match the 
   received I2s against the state, as discussed in Section 4.1.1.

8.3  Processing R1 packets

   A system receiving an R1 first checks to see if it has sent an I1
   to the originator of the R1 (i.e., it is in state E1).  If so,
   it SHOULD process the R1 as described below, send an I2, and go
   to state E2, setting a timer to protect the I2.  If the system is in 
   state E0 or state E2 with respect to that host, it SHOULD silently drop 
   the R1.  If the system is in state E3, it SHOULD process with a
   Security Association and Birthday check as described in Section 5.3, 
   before further processing below.  In this last case, if the R1 is
   successfully processed, the system sends an I2, sets a retransmit
   timer to protect the I2, drops its old Security Association, and goes 
   back to state E2. [Q. Is receipt of R1 in state E3, triggering a
   SA reestablishment, a potential replay attack?]

   Assuming the system has decided to process the R1, the following
   steps apply.  The R1 SHOULD validate the HIP signature before
   applying further packet processing, according to Section 6.3.10.  

   The R1 packet may have the C bit set-- in this case, the system 
   should anticipate the receipt of HIP CERT packets that contain the
   host identity corresponding to the responder's HIT. [Q:  Is this
   a substate that needs to be defined ("waiting for CERT")?]

   The R1 packet may have the A bit set-- in this case, the system
   MAY choose to refuse it by dropping the R1 and returning to state E0.
   [Q.  DoS attack by early spoofed anonymous R1, similar to early 
   false DNS replies?].  If the A bit is set, the Responder's HIT is 
   anonymous and should not be stored or validated against a Host 
   Identity.  If the A bit is not set, the system SHOULD attempt to 
   validate the HIT against the received Host Identity.  Furthermore, 
   if the Initiator specified the Responder's HIT in the I1, it SHOULD 
   also check that the received HIT agrees with the one originally 
   selected.  Finally, the Initiator's HIT MUST correspond to the HIT 
   used in the original I1.
   
   The system MUST store the received Birthday count for future 
   reference.  The system MUST attempt to solve the cookie puzzle, trying 
   for a number of tries up to the minimum of the degree of difficulty 
   specified by the K value in the cookie parameter or an implementation- 
   or policy-defined maximum retry count.  If the cookie puzzle is not 
   successfully solved, the implementation may either resend I1 or  
   abandon the HIP exchange. 
 
   The system computes standard Diffie-Hellman keying material according 
   to the public value and Group ID provided in the DIFFIE_HELLMAN
   parameter.  The Diffie-Hellman keying material Kij is used for key
   extraction as specified in Section 9.  [Q. What happens if D-H
   Group ID not supported? Start over?]

   The system selects the HIP transform and ESP transform from the
   choices presented in the R1 packet and uses the selected values
   subsequently when generating and using encryption keys, and when
   sending the I2.   
 
   Upon sending an I2, the sender shall transition to state E2 and
   start a timer whose timeout value should be larger than the 
   worst-case anticipated RTT, and shall increment a timeout counter 
   associated with the I2.  The sender SHOULD retransmit the I2 upon a 
   timeout and restart the timer, up to a maximum of N2 tries.

8.4 Processing I2 packets

   Upon receipt of an I2, the system MAY perform initial checks
   to determine whether the I2 corresponds to a recent R1 that has
   been sent out, if the Initiator keeps such state.  For example,
   the sender could check whether the I2 is from an address or HIT
   that has recently sent it an I1.  If the I2 is considered to
   be suspect, it MAY be discarded by the system.

   Otherwise, the HIP implementation SHOULD process the I2.  
   Assuming that the Responder HIT corresponds to one of the 
   implementation's HITs, the system MUST first validate the solution 
   to the cookie puzzle by computing the SHA-1 hash described in 
   Section 7.3,  Next, the system MUST verify the HIP_SIGNATURE 
   according to Section 6.3.9 and Section 7.3.  To decrypt the 
   HOST_ID (or HOST_ID_FQDN) corresponding to the signature, the 
   system must first derive Diffie-Hellman keying material based on 
   the public value and Group ID in the DIFFIE_HELLMAN parameter.  
   The encrypted HOST_ID or HOST_ID_FQDN is decrypted by the HIP 
   Initiator key defined in Section 9.  The implementation SHOULD 
   also verify that the Initiator's HIT corresponds to the Host 
   Identity sent in the I2.  If these checks are valid, then the 
   system proceeds with further I2 processing; otherwise, it discards 
   the I2 and remains in the same state.

   The I2 packet may have the C bit set-- in this case, the system 
   should anticipate the receipt of HIP CERT packets that contain the
   host identity corresponding to the responder's HIT. 

   The I2 packet may have the A bit set-- in this case, the system
   MAY choose to refuse it by dropping the I2 and returning to state E0.
   If the A bit is set, the Initiator's HIT is anonymous and should not 
   be stored or validated against a Host Identity.  If the A bit is not 
   set, the system SHOULD attempt to validate the HIT against the 
   received Host Identity.  Furthermore, the system SHOULD also check 
   that the Responder HIT corresponds to one of the system's HITs 
   offered in the R1.
   
   The I2 packet may have the E bit set.  If so, the HIP implementation
   will treat the ESP sequence numbers as 64 bit quantities as described
   in Section 11.4.

   The Birthday count is extracted from the BIRTHDAY_COOKIE parameter
   and stored for future use.

   The SPI_LSI field is parsed to obtain the SPI that will be used
   for the Security Association inbound to the Initiator.  
   [XXX:  LSI unused for now?...]

   The I2 MUST have a single value in each of the HIP_TRANSFORM and
   ESP_TRANSFORM parameters, corresponding to the values selected by
   the Initiator, and they must each match one of the values 
   offered to the Initiator in the R1 packet.  Other keying material 
   can be obtained at this time according to Section 9.

   Upon successful processing of an I2 in states E0, E1, and E2, an
   R2 is sent and the state machine transitions to state E3.  Upon
   successful processing of an I2 in state E3 (which includes a
   successful Birthday check), the old Security Association is
   dropped and a new one is installed, an R2 is sent, and the state 
   machine cycles back to E3.

8.5 Processing R2 packets

   An R2 received in states E0, E1, or E3 results in the R2 being dropped
   and the state machine staying in the same state.

   If an R2 is received in state E2, it SHOULD be processed.  The 
   system MUST verify that the HITs in use correspond to the HITs
   that were used in R1.  The HIP signature MUST be verified
   according to the procedures in 6.3.9.

   The R2 packet may have the E bit set.  If so, the HIP implementation
   will treat the ESP sequence numbers as 64 bit quantities as described
   in Section 11.4.  

   The SPI_LSI field is parsed to obtain the SPI that will be used
   for the Security Association inbound to the Responder.  
   [XXX:  LSI unused for now?...]

   Upon successful processing of the R2, the state machine moves
   to state E3.

8.6 Processing NES packets

   The ESP Sequence Number and current SPI are included to provide
   replay protection for the receiving peer.  The old SA MUST NOT be
   deleted until all ESP packets with a lower Sequence Number have been
   received and processed, or a reasonable time has elapsed (to account
   for lost packets).  If the Sequence Number is the replay window is
   greater than the number in the NES packet, the NES packet MUST be
   ignored.  If the SPI number does not match with an existing SPI
   number used, the NES packet must be ignored.

   The peer that initiates a New SPI exchange MUST include a Diffie-
   Hellmen key.  Its peer MUST respond with a New SPI packet, an MAY
   include a Diffie-Hellman key if the receiving system's policy is to
   increase the new KEYMAT by changing its key pair.

   When a host receives a New SPI Packet with a Diffie-Hellman, its next
   ESP packet MUST use the KEYMAT generated by the new Kij.  The sending
   host MUST expect at least a replay window worth of ESP packets using
   the old Kij.  Out of order delivery could result in needing the old
   Kij after packets start arriving using the new SA's Kij.  Once past
   the rekeying start, the sending host can drop the old SA and its Kij.

   The first packet sent by the receiving system MUST be a HIP New SPI
   packet.  It MAY also include a datagram, using the new SAs.  This
   packet supplies the new SPI for the rekeying system, which cannot
   send any packets until it receives this packet.  If it does not
   receive a HIP New SPI packet within a reasonable round trip delta, it
   MUST assume it or the HIP Rekey packet was lost and MAY resend the
   HIP New SPI packet or renegotiate HIP as if in a reboot condition.
   The choice is a local policy decision.

   This packet MAY contain a Diffie-Hellman key, if the receiving
   system's policy is to increase the new KEYMAT by changing its key
   pair.

8.7 Processing BOS packets

8.8 Processing CER packets

---

From: [email-masked] (Pekka Nikander)
Date: Fri Sep 5 08:46:00 2003

> I did not touch the BOS and CER packet processing.

Thanks a lot!

I am right now editing the text to XML format.

Two questions so far:

>    Identity.  

I don't understand why the HIT should not be validated.  Please explain.

>    be stored or validated against a Host Identity.  If the A bit is not 

I don't understand why the HIT should not be validated.  Please explain.

--Pekka