Subject: [Hipsec] API and LSI resolution

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

Below is proposed text that deals with the API and LSI issues 
that have been discussed.  Note that this text does not address
the IANA issue previously raised regarding 1.0.0.0/8 range for LSIs.

3.2 Local Scope Identifier (LSI)

   LSIs are 32-bit localized representations of a Host Identity.  The
   purpose of an LSI is to facilitate using Host Identities in existing
   IPv4 based protocols and APIs.  The LSI can be used anywhere in system
   processes where IP addresses have traditionally been used, such
   as IPv4 API calls and FTP PORT commands.

   The LSIs MUST be allocated from the 1.0.0.0/8 subnet.  That makes it
   easier to differentiate between LSIs and IPv4 addresses at the API
   level.  The low order 24 bits of an LSI MUST be equal to the low 
   order 24 bits of the corresponding HIT.  

   A host performing a HIP handshake may discover that the LSI formed from 
   the peer's HIT collides with another LSI in use locally (i.e., the lower 
   24 bits of two different HITs are the same).  In that case, the host MUST 
   handle the LSI collision locally such that application calls can be 
   disambiguated.  One possible means of doing so is to perform a Host NAT 
   function to locally convert a peer's LSI into a different LSI value.  This 
   would require the host to ensure that LSI bits on the wire (i.e., in the 
   application data stream) are converted back to match that host's LSI.  Other 
   alternatives for resolving LSI collisions may be added in the future.

<DELETE SECTION 3.4, RENUMBER 3.5 to 3.4>

6.2 HIP parameters

      TLV               Type  Length     Data

      SPI               1     16         Remote's SPI

6.2.3 SPI

   The SPI parameter contains the SPI that the receiving host must
   use when sending data to the sending host.

       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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              SPI                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type         1
      Length       4 
      SPI          Security Parameter Index

<MAKE GLOBAL CHANGE:  s/SPI_LSI/SPI,  and repair the surrounding text>

8.7 Processing incoming I2 packets

<DELETE item 15. below>

   15.  If the system supports LSIs, it should check that the received
        LSI is an acceptable representation of its own identity, and
        create an appropriate state.  If the LSI is not acceptable, the
        behaviour is currently undefined; see Appendix A.

8.8 Processing incoming R2 packets

<DELETE item 7 below>

   7.  If the system supports LSIs, it should check that the received
       LSI is an acceptable representation of its own identity, and
       create an appropriate state.  If the LSI is not acceptable, the
       behaviour is currently undefined; see Appendix A.

<REPLACE Appendix A with the below>

Appendix A. API issues

   The following text is informational and may be expanded upon or 
   revised in a separate Informational document.    

   HIP may be used to support application data transfers in one of three
   ways:
   1) the application may be HIP-aware and may explicitly use a
      HIP-based API and/or resolver library;
   2) the application may not be HIP-aware but may be provided with HITs
      or LSIs in place of IP addresses as part of the address resolution 
      process; and 
   3) the application may or may not be HIP-aware and may present IP 
      addresses to the system, but the system may decide to 
      opportunistically invoke HIP or use a pre-existing HIP-based SA 
      on its behalf.

   The first case is the most straightforward.  The HIP-based API 
   is outside the scope of this document.  

   The second case is one way to provide HIP support to non-HIP-aware
   applications.  HITs may be stored in the DNS or some other 
   infrastructure, and the resolver library may choose to supply a 
   querying application with a HIT or LSI in place of an IP address.  
   Note that if the application truly needs IP addresses for a domain 
   name for some reason (e.g., a diagnostic application, or for use in 
   a referral scenario to a non-HIP-based host), blindly providing HITs 
   or LSIs in place of actual IP addresses may cause some applications 
   to break.

   In both of the first two cases, the means whereby a system can
   resolve an LSI or HIT to an IP address, when such a mapping is
   not locally cached in the system, is outside the scope of this
   document.  

   In the third case, the system is explicitly invoking HIP to a
   particular destination IP address on the basis of a local policy 
   decision.  This approach resembles the way that opportunistic
   IPsec works.  Effectively, this approach is implicitly associating 
   IP addresses with host identities, and is prone to certain failures 
   or ambiguity in an environment where IP addresses are dynamic (e.g., 
   an application connects to an IP address, the peer host moves at 
   some later time, then another host acquires the old IP address, 
   and the system again receives a request to connect to that IP
   address, in which case it is ambiguous whether the application wants
   to connect to the host previously at that IP address or the new
   host at that address).

   If HIP is used to support an application, the application data
   stream may contain either IP addresses or LSIs or HITs in place
   of the IP addresses.

---

From: [email-masked] (Pekka Nikander)
Date: Mon Mar 29 02:45:05 2004

>    order 24 bits of the corresponding HIT.

I think that we want to say either:

   a) The default low order 24 bits of an LSI MUST   be equal..., or
   b) The         low order 24 bits of an LSI SHOULD be equal....

Otherwise we seem to be painting ourselves into a corner.

>    alternatives for resolving LSI collisions may be added in the 

Ok.

> <REPLACE Appendix A with the below>

Looked ok.

--Pekka

---

From: [email-masked] (Pekka Nikander)
Date: Mon Mar 29 02:58:01 2004

Ok.

Looked ok.

--Pekka