2.3.6 Host Identity Protocol (hip)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional HIP Web Page

Last Modified: 2004-11-02

Chair(s):

David Ward <dward@cisco.com>
Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>

Internet Area Director(s):

Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Margaret Wasserman <margaret@thingmagic.com>

Mailing Lists:

General Discussion: hipsec@honor.trusecure.com
To Subscribe: hipsec-request@honor.trusecure.com
In Body: With a subject line: subscribe
Archive: http://honor.trusecure.com/pipermail/hipsec/

Description of Working Group:

The Host Identity Protocol (HIP) provides a method of
separating the end-point identifier and locator roles of
IP addresses. It introduces a new Host Identity (HI)
name space, based on public keys. The public keys are
typically, but not necessarily, self generated.

The specifications for the architecture and protocol
details for these mechanisms consist of:

        draft-moskowitz-hip-arch-05.txt (at RFC editor) and
        draft-moskowitz-hip-08.txt (soon -09.txt)

There are five publicly known, interoperating
implementations, some of which are open source.

Currently, the HIP base protocol works well with any pair
of co-operating end-hosts. However, to be more useful
and more widely deployable, HIP needs some support from
the existing infrastructure, including the DNS, and a new
piece of infrastructure, called the HIP rendezvous
server.

+-------------------------------------------------------+
| The purpose of this Working Group is to define the    |
| minimal infrastructure elements that are needed for  |
| HIP experimentation on a wide scale.                  |
+-------------------------------------------------------+

In particular, the objective of this working group is to
complete the base protocol specification, define one or
more DNS resource records for storing HIP related data,
to complete the existing work on basic mobility and
multi-homing, and produce Experimental RFCs for these.

Note that even though the specifications are chartered
for Experimental, it is understood that their quality and
security properties should match the standards track
requirements. The main purpose for producing
Experimental documents instead of standards track ones
are the unknown effects that the mechanisms may have on
applications and on the Internet in the large.

It is expected that there will be a roughly parallel,
though perhaps considerably broader, IRTF Research Group
that will include efforts both on developing the more
forward looking aspects of the HIP architecture and on
exploring the effects that HIP may have on the applications
and the Internet.

The following are charter items for the working group:

1) Complete the HIP base protocol specification.
  Starting point: draft-moskowitz-hip-08.txt (or newer)

2) Complete the basic mobility and multi-homing support for HIP.
  Starting point: draft-nikander-hip-mm-01.txt (or newer)

While this work partially overlaps the work in Mobile
IP and Multi6 Working Groups, it is very different in
the sense that is based on the Experimental HIP
specification, and cannot function without it.

3) Define one or more new DNS Resource Records for
  storing HIP related data, such as Host Identifiers and
  Host Identity Tags (HITs). This task explicitly
  excludes the task of defining reverse DNS entries
  based on HITs.

4) Define a basic HIP rendezvous mechanism.

  A basic HIP rendezvous server allows mobile and
  non-mobile HIP hosts to register their current IP
  addresses at the server. Other hosts can then send
  the initial I1 packets to the rendezvous server, which
  forwards the packets to the HIP host's current address.

  This task explicitly excludes solving more general
  problems, such as the referral problem. Also excluded
  is the problem of finding the right rendezvous server.
  It is expected that the DNS records will be used for that.

  The Working Group bases all the work on the HIP achitecture
  specification (as defined above).

5) Complete the HIP Architecture specification
  Starting point: draft-moskowitz-hip-arch-06.txt

Goals and Milestones:

Done  First version of the HIP basic mobility and multi-homing mechanism specification.
Done  First version of the HIP DNS resource record(s) specification.
Done  First version of the HIP basic rendezvous mechanism specification.
Dec 04  WGLC on the HIP architecture specification
Jan 05  Submit the HIP architecture specification to the IESG
Mar 05  WG LC on the base protocol specification
Mar 05  WG LC on the base protocol specification
Apr 05  Complete the base protocol specification and submit it to the IESG for Experimental
Apr 05  WG LC on the HIP basic mobility and multi-homing specification.
Apr 05  WG LC on the basic HIP rendezvous mechanism specification.
May 05  Submit the HIP DNS resource record(s) specification to the IESG for Experimental.
May 05  Submit the HIP basic mobility and multihoming specification to the IESG for Experimental.
May 05  Submit the basic HIP rendezvous mechanism specification to the IESG for Experimental.
May 05  Recharter or close the WG.

Internet-Drafts:

  • draft-ietf-hip-base-01.txt
  • draft-ietf-hip-arch-00.txt
  • draft-ietf-hip-mm-00.txt
  • draft-ietf-hip-dns-00.txt
  • draft-ietf-hip-rvs-00.txt

    No Request For Comments

    Current Meeting Report

    59th IETF HIP Minutes

    Minutes, HIP WG, 61st IETF

    Notes by Andrew McGregor, and  Bob Salmi
    Minutes edited by David Ward.
    Meeting chaired by Gonzalo Camarillo (David Ward absent).

    HIP Meeting
    Detailed Discussions


    HIP Meeting, Wednesday, Nov 8, 2004, 1300-1500


     1300 Agenda Bash - Chairs

     1305 Status of Work-  Chairs

     

     1315 Architecture

    draft-ietf-hip-arch-00.txt  (currently under WGLC)

    Pekka Nikander

     

     1335 Base Specification

    draft-ietf-hip-base-01.txt

    Petri Jokela

     

     1355 DNS Extensions

    draft-ietf-hip-dns-00.txt

    Julien Laganier

     

    1410 Mobility and Multi-Homing

    draft-ietf-hip-mm-00.txt

    Thomas Henderson

     

     1430 Rendezvous

    draft-ietf-hip-rvs-00.txt

    Julien Laganier

     

     1500 Meeting Ends

     

    Detailed Discussions

    Topic: Status
    charter update

     --Jan 05: submit HIP architecture to IESG

     --Apr 05: complete base spec and submit as experimental

     --May 05: dns, mobility and multihoming and rendezvous to IESG for experimental

    agenda bash

     -- no changes


    Open Issues in the Arch Specification
    1) Architecture doc draft-ietf-hip-arch-00.txt -- Pekka Nikander

    • This document is in Last Call untill Nov. 15th please comment.
    • The documents goal is to create a stable reference point for defintion of HIP. Descended from Bobs original document.
    • Submit to IESG after LC comments have been resolved. RFC Editor asking for publication ASAP.

       Comments so far:

       Some general editorial comments and some clarifications were asked for.

       One substantial comment  -- what is the correct term for ephemeral HIs

         -- anonymous ?

         -- private ?

         -- unpublished ?

               Currently unpublished is  used in spec which may not be a completly accurate description of the intent of these HI's

               If you have a better naming option please submit the comments.

          Document next steps

    1. wait for additional comments
    2. fix issues if any
    3. submit to IESG by end of year

     

         Working Group Chair comment

              We have not received lots of comments but their seems to be lots of  interest in this. Please read and comment.

     

    Open Issues in the Base Specification

    2) Base Spec draft-ietf-hip-base-01.txt -- Petri Jokela

       Changes and open issues from 00.txt

    See issue tracker on hip4inter.net

       List of closed issues

    Issue #46: 128 bit LSI's

          both 32 and 128 bit LSI's fgor v4 and v6 compatibility

          128 bit lsi's for resolving HIT/IPv6 collisions

          LSI subnets still TBD

          HIT's changed to 128 bits

    Issue 48: remove BOS aand PAYLOAD packets

          not critical at this point so Bootstrapping and Payload packets will be defined in a later draft.

    Issue 39 removal of HIP state

          close/close-ack mesages added and closing and closed state added

    Issue 47  Make RSA mandatory algorithm

          changed mandatory implementation from DSA to RSA

          DSA is still recommended

       Transform algorithm change

          move from 3des to aes

       Make HIP SIGMA compliant

          I2: new HMAC TLV covering the whole packet

          R2: HMAC calculation also covers responders HOST_ID

     

        List of open issues

    Issue 31 IANA allocations

           LSI 1.0.0.0/8 allocation

           128 bit LSI prefix allocation

    Issue 37: notification data field usage

    Issue 49:  Iana considerations needs to be wriiten

    Issue 50: remove appendix E  Running HIP over IPV4 udp, this needs to be a sepaate draft

    no questions/comments on the base spec doc in the room

        please comment on the mailing list

     

    Open Issues in the DNS Specification

    3) HIP dns extensions  draft-ietf-hip-dns-00.txt -- Julien Laganier

        goals

    2 new dns RR's used by Hip nodes

            HIPHI for stroring a HIP nodes HI and/or HIT similar to IPSECKEY RR

            HIPRVS for storing a HIP nodes Rendezvous Servers FQDN or IP Addr

         document changes

         -- Changed HIT storage to variable length, type and algorithim HIT's

         -- support for multiple RVS in same HIPRVS RR

         -- reuse most of the type values in IANA registries for IPSECKEY RR

         -- Security considerations section

         An open issues using multiple HI's and IP's

            What if FQDN maps to multiple HI's

                Each HI's maps to a particular set of IP addrs;

            Suggestion FQDN might map to multiples sub-FQDN's, each of them mapping to a flat set of HI's and IPs

         A lively discussion of considering these changes to DNS occured

         -- Discussion of DNS mapping host name to get ip address of host vs  mapping to a provider of a service

    Pekka N: simplest if names resolve to single HI

    Dave: If we do this, we limit the applicability severely; we are losing the boundaries of a 'host'.

    Pekka N: does this simplification cause any harm?

    Bill: don't tell me how to run my DNS -- DNS is a mapping that can do this.

    Pekka N: Looks like DNS may well be a temporary arrangement.  HI to IP Address mapping is problematic.

    Dave: difficult time getting required detail, but can't change meaning of domain name.

    HIP is experimental, so use that to allow for troubles.

    Pekka N: DNS experts say numbers of HIs per name are necessary.  Don't know how to get HI to IP mapping in that case.

    Tim Shepard: DNS maps names to IP, have HIP ask the question.  Tim wants HIP to be largely independant of the DNS.  SSH has been useful for a long time without keys in DNS, why can't HIP be.

    Gonzalo: HIP query extension like that is RG material.

    Christian Huitema: Does this make a circular dependency?

    Bob M: Useful to know that a HIT/HI really is bound to the service you think it is, DNSSEC buys something.  These RRs are a way to get the information into the DNS.

    Eric Nordmark:  If you get multiple HIs and IPs, and don't know it's a host or a service.  During initial exchange, if we get locators for that HI, then we're OK.

    Pekka N: If we get that, just make exchange and check for a valid responder HIT for one of the HIs that came back.

    Julien: Separate RRs or subtype?

    Dave: Subtyping is bad.

    Gonzalo: People love to have discussions, but details go away.  Editors are complaining about lack of detail feedback.

     

    Open Issues in the Mobility and Multihoming Specification

    4) mobility and multihoming extensions -- Pekka/Tom Henerson

       goals

    --session persitence across multiple locations

            simultaneously(multi-homing)

            sequentially(mobility)

            addr familes v4/v6 transition)

        --address verification

        --locator chnage with/wthout rekeying

        --declaring a preferred address

        --announcing additional locators in base handshake

        --middlebox friendliness

       non-goals

    --rendezvous and proxying

        --location privacy

        --multihoming with legacy hosts

        --transport layer issues

            mtu discovery, congestion control, qos

    ???: what did you mean by middle box friendliness?

           This is an attempt to allow middle boxes to snoop protocol and do the right thing.

           Did we get this right please comment

        new updates

     SA's are paired not assymetric to avoid ambiguity when rekeying multihoming is restricted for failover now , it's not load balancing yet clarification on use of non-global addresse some additional clarifications needed -- implementation experience 3 implementations but not enough protocol use yet.

       Whats  missing?

          policy considerations

          security analysis and considerations.

        issues in existing draft

        --parameter ordering for middlebox friendliness -- duplication of SPI values

        --are we doing enough for NAT traversal -- more analysis needed

        --multihoming design is probably not clean or understood enough

        next steps

        --informal middlebox design team/reviwers needed and

             resolve interactions with mobility and multihoming

        --need experimentation with real multihoming

        --security and policy sections need to be written

    ???: what is in mind for authentication with say a firewall.

           we need something like a registration protocol for this. 

           some work in the RG on this.

           might need to send multiple registrations -- one for each middlebox device

    ???: It might be difficult to do this with low end nat boxes as these boxes in  the low end are averse to ading more code.  some work going on in other WG's on this as well.

     

    Open Issues in the Rendezvous Server Specification

    6) rendezvous server draft-- Julienb Laganier

       Hip rendezvous extensions draft-ietf-hip-rvs-00.txt

        Goal  

    HIP nodes might frequently change it's ip addrs

                might maintatin rechability using it's rendezvous server

        What changed?  

    Femoved IP concealing extensions

       Added support for oportunistic initiators relaying I1 and r1

       Add security and IANA Considerations

       Complete REDIRECT packet descriptions

       Some new header extensions  new parameters: RVA_REQUEST RVA_rewply from, to, via_RVS

       See slides for descriptions

        next steps

        Does the protocol need all these relaying redirect modes?

        Is the to paramter needed ? echo_reply is required anyway

        Should we split the current spec into redezvous service and  hip registration with the rendezvous server

     

    Pekka N: It's too complicated and too many options make this too hard to achieve interoperability

                  we need a tunnel rendezvous server to tunnel packes back to the real host

                  need a simple rewrite of the packet

                  maybe we should just rewrite instead of tunneling.

                  possilby redirect should be split out.

    ???: Is it too early to talk about rewriting the packet -- what if your

                  authenticationg packet headers

                  we only relay hip packets

    ???: rewriting might be a problem for like ah

    ???: this is undefined how you'd run say tcp on top of hip -- need clarifcation

                  that if you try this you might run into problems.

     

    Done with agenda

     

    Reminder the research group is meeting during fridays session

    Slides

    Status/Agenda
    Architecture
    Base Spec
    Multihoming and Mobility
    RVS
    DNS
    Ad-hoc Meeting on NATs