Subject: [Hipsec] A concrete HIP WG & RG proposal as feed for thought

From: [email-masked] (Pekka Nikander)
Date: Mon Dec 1 08:52:01 2003

Folks,

Taking a different angle on how to organize the HIP work,
I think that it is also useful to think in very concrete
terms.  My previous mail tried to focus on the various
in-the-large aspects that we have to consider here.  This
mail puts forward a concrete but certainly not ready proposal
for a HIP WG and an RG with a slightly larger scope.  Both
groups could use the same mailing list, at least initially.

HIP WG

Chairs: David Ward, Gonzalo Camarillo

A 6-9 month WG that would produce the following documents:

  1. HIP base protocol specification.  Experimental RFC.
     Base document: draft-moskowitz-hip-08/09.txt
     Document Editor: Petri Jokela

  2. Basic mobility and multi-homing with HIP.  Experimental RFC.
     Base document: draft-nikander-hip-mm-01.txt (-00 is not good enough)
     Document Editor: Pekka Nikander

  3. DNS resource record for storing HIP Host Identifiers and HITs.
     Experimental RFC.
     Base document author: Michael Richardson
     Document Editor: Needs to be defined

     This is a simple RR that is very much like IPSECKEY RR.
     It just stores a public key and/or a hash of a public key.

  4. A simple rendezvous server for HIP.  Experimental RFC.
     Base document author: Pekka Nikander
     Document Editor: Needs to be defined

     This is a simple node that forwards I1 packets to a
     registered IP address and does nothing else.  We also
     need a protocol that allows a HIP host to change the
     registered IP address at the rendezvous server.  The
     latter could be a new HIP packet, basically meaning that
     the rendezvous server would need to run HIP with the
     hosts that it servers.  It could also be something much
     simpler, e.g., I1 -> R1 -> AddressChange, where the
     AddressChange would be a packet that implements some
     properties from I2 but instead of creating a HIP state
     just updates the I1 forwarding state.

Instead of having Michael to write the -00 version of the
DNS RR document and me the -00 version of the simple
rendezvous server, we could have design teams.  However, I
do believe that the ideas are simple enough that it is probably
better to have single individuals to write the initial drafts.
(Provided, of course, that those individuals do have cycles.)

BEET seems to be moving to MOBIKE, and going standards track.

LOC/ID SPLIT AND HIP (LISHIP) RG

Chairs: To be determined (I could be one)

An RG with a 2-3 year clear two threaded goal:

  - to explore solutions to the referral problem caused by
    the id/log split

  - to co-ordinate and follow the experimental deployment of
    HIP in the Internet

Documents to be produced:

  -  HIP experimentation guide.  Informational RFC.

     The goal of this document is to give practical instructions
     on how to join the HIP experimentation.  It must also contain
     suitable warnings about the potential dangers, like some
     applications breaking etc.

  -  DHT based information lookup service.  Experimental RFC.

     A new, flat "DNS"?  How to build it?  How to make it
     economically feasible?  I think that this is the really
     tough problem, and not related only to HIP but also to
     most other id/loc proposals.

  -  Other referral solutions (but DHT) for HIP.  Informational RFC?

     Could there be other solutions to solve the referral problem,
     especially with HIP?  Hierarchical HITs is one possibility,
     which was discussed in earlier HIP architectural drafts but
     removed later in the process.  Another possibility of using
     peers as limited rendezvous server was invented during the
     Minneapolis meeting.  I guess there might be others, too.

  -  Advanced HIP rendezvous server / proxy / forwarding agent.
     Experimental RFC.

     A node that provides "advanced" rendezvous / proxy / packet
     forwarding functions for HIP nodes.  If this was to be produced
     at the IETF, I guess one would need a requirements document first.
     However, being IRTF work I'd much more would like to see people
     to implement various options, and the document to be produced
     as a merger of results from implementation projects.

     There are already a couple of research papers that have
     appeared in this area, and I guess there will be more.
     This could be moved to the WG later once the WG has completed
     its initial items.

  -  Dynamic DNS updates secured with HIP.  Experimental RFC.

     Once we start storing HIs (public keys) into the DNS, could
     we allow the use of the same public keys to update other
     DNS records that are related to that public key?  What should
     the protocol be like?  Like the rendezvous protocol outlined
     in the #4 WG work item?

     This might result in a future item for the dnsext WG.

  -  NAT traversal with HIP.  Experimental RFC.

     I guess there might be multiple approaches in this area.
     Personally, I don't care much about this as I sincerely
     hope that IPv6 would come and make NATs to go away.

  -  Applications guideline.  Informational RFC.

     How something like HIP would affect the applications.
     There is also a new mailing list, aulli, for discussing
     some related aspects.

Now, as you can see, there seems to be enough of food for both
a working group and a research group.  There seems also to be
enough of people that actually want to use HIP so that the WG
would most probably be manned and produce useful things.  On the
other hand, so far there definitely has been enough of people
interested on researching HIP so that I would expect the RG to
be fairly lively and actually produce output.

--Pekka Nikander

---

From: [email-masked] (Steven M. Bellovin)
Date: Mon Dec 1 13:45:01 2003

>BEET seems to be moving to MOBIKE, and going standards track.

The status of BEET and its relationship (if any) to MOBIKE is still
unsettled.

		--Steve Bellovin, http://www.research.att.com/~smb