Subject: [Hipsec] native HIP API

From: Miika Komu <[email-masked]>
Date: Thu, 8 Jul 2004 13:40:14 +0300 (EEST)

There were some people interested in the HIP userspace API issues and I
promised to get back to the topic later by providing some background
information.

My master's thesis proposes a new API for HIP aware applications. It is
fully not completed yet but you can download a snapshot from the url
below:

http://hipl.hiit.fi/hipl/hip-native-api-snapshot-20040708.pdf

I suggest that we continue the discussion on the hipsec research mailing
list although I crossposted this email.

Summary:

  The purpose of the native HIP API is to provide an explicit interface
  for HIP aware applications. It provides two new features compared to the
  "legacy HIP API". Applications are given the opportunity to control HIP
  connection attributes. Applications can also provide their own Host
  Identities to the host.

  The native HIP API is based on the BSD sockets API. The sockets API
  design is extended with two significant changes: a new protocol family
  (PF_HIP) and a new application identifier (EID).

  The new family requires a new HIP specific socket handler. The socket
  handler acts as a EID-to-HI address translator. It also allows  setting
  and querying of HIP specific socket options. The new socket handler
  isolates the HIP sockets from the IPv4/IPv6 sockets.

  The Endpoint Identifier Descriptor (EID) is an opaque handle to a HI. It
  hides the details of the variable length HIs and the associated
  ephemeral locators. The EID cannot be used as a referral, but there are
  interfaces for retrieving the HIs and locators corresponding to the EID.

  The EID is preferred as the AID instead of HIT for a few reasons. It
  provides forward compatibility with the HIP protocol. If the length of
  HIT were to change, the changes needed in the userspace would be
  minimal. The EID concept can also be beneficial for other protocols with
  the id/locator split.

  The API provides a new endpoint resolver, which is syntactically similar
  to the sockets API resolver. Basically, the resolver inputs a hostname
  and returns the EIDs corresponding to the hostname. The resolver makes
  the HI-to-locators mapping management transparent to the "typical"
  applications. However, the API allows the "advanced" applications to
  configure the mappings manually.

  The API supports explicit controlling of opportunistic HIP mode.
  Falling back to plain TCP/IP is also possible if the DNS does not
  contain the HIs of the peer.

  I implemented the socket handler into the networking stack, It supports
  the basic functionality of the API. It acts as a wrapper to IPv6 socket
  handler and it was not very difficult to implement. I also ported a
  telnet client and server to use the API with little effort.

I writing an IETF draft for API proposal, but first, I would like receive
some feedback and open a free discussion on the topic. I have already some
specific questions in mind, but feel free to comment on anything.

Questions:

  * Is the EID approach an overkill? It is quite easy to replace the EID
    with a HIT in the API, if some people prefer HITs as the AID.

  * Opinions on the PF_HIP family?

P.S. I am on a holiday next week and cannot read my email (expect a delay
     on the replys).

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec