2.3.5 Host Identity Protocol (hip)
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:
http://hip.piuha.net/ -- Additional HIP Web Page
NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.
Last Modified: 2004-05-18
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).
Goals and Milestones:
Mar 04 | | WG LC on the base protocol specification |
Mar 04 | | First version of the HIP basic mobility and multi-homing
mechanism specification. |
Mar 04 | | First version of the HIP DNS resource record(s) specification. |
Apr 04 | | Complete the base protocol specification and submit it to the
IESG for Experimental |
Apr 04 | | First version of the HIP basic rendezvous mechanism
specification. |
Aug 04 | | WG LC on the HIP DNS resource record(s) specification. |
Sep 04 | | Submit the HIP DNS resource record(s) specification to the IESG
for Experimental. |
Nov 04 | | WG LC on the HIP basic mobility and multi-homing specification. |
Nov 04 | | WG LC on the basic HIP rendezvous mechanism specification. |
Dec 04 | | Submit the HIP basic mobility and multihoming specification to
the IESG for Experimental. |
Dec 04 | | Submit the basic HIP rendezvous mechanism specification to the
IESG for Experimental. |
Jan 05 | | Recharter or close the WG. |
Internet-Drafts:
- draft-ietf-hip-base-00.txt
No Request For Comments
Current Meeting Report
60th IETF HIP Minutes
Minutes, HIP WG, 60th IETF
Notes
by Thomas Henderson, Gabriel Montenegro, and Andrew McGregor. Minutes edited
by Gonzalo Camarillo. Meeting chaired by Gonzalo Camarillo and David
Ward.
HIP Meeting,
Thursday, August 5, 2004, 0900-1130
Topic: Status Slides presented:
pres-ietf60-hip-chairs.ppt Discussions led by: Chairs
Issue: We are
behind schedule. We need to update our milestones.
Topic: Base Spec Slides presented:
pres-ietf60-hip-base-spec-jokela.ppt Relevant document:
draft-ietf-hip-base-00.txt Discussions led by: Petri
Jokela
Issue: most of the open issues closed. Feedback is requested on
the few minor ones that are still open in the issue tracker at
http://hip4inter.net. In particular, the issue about one hip host losing state
while the other stays up (close-ack message), the LSI space allocation issue,
and the notification data field issue.
Information: interop text among
three implementations (Ericsson,Boeing, and HUT) carried out succesfully during
the week of the IETF.
Topic: Making HIP
Multi6 Friendly Slides presented:
pres-ietf60-hip-multi6-henderson.ppt Relevant document:
draft-nikander-multi6-hip-01.txt Discussions led by: Thomas
Henderson
Information: HIP problems from a multi6 perspective:
non-standard (experimental) approach, absence of supporting infrastructure (dns,
identifier lookup), HIP handshake too heavywheight, IPsec mandatory too heavy,
HIT's as app level id's may break referrals, privacy concerns with non-ephemeral
identifiers. Issue: HIP may be adopted as a multi 6 solution or be
cherry-picked. So, should any changes be made to HIP to address
multi6? Conclusion: We will not make important changes to make HIP multi6
friendly. We will finish the the charter as planned (although we will finish it
a little later than initially planned).
Topic: Backwards Compatible API Slides
presented: pres-ietf60-hip-legacy-api-komu.pdf Discussions led by:
Miika Komu
Issue: Prons and cons of using a HIP native API versus using a
transparent API (i.e., the resolver spoofs the IP address returned to
applicationand returns a HIT instead). Conclusion: needs list
discussion. Observation: native APIs are discussed in the research
group.
Topic: Mobility and
Multihoming Slides presented:
pres-ietf60-hip-mm-henderson.ppt Relevant document:
draft-nikander-hip-mm-02.txt Discussions led by: Thomas
Henderson
Issue: should we adopt this draft as a WG item? Conclusion:
strong consensus to adopt it.
Topic: DNS
Issues Slides presented: pres-ietf60-hip-dns-laganier.pdf Relevant
document: draft-nikander-hip-dns-00.txt Discussions led by: Julien
Laganier
Issue: need DNS experts to have a look at the
draft. Conclusion: Rob Austein offers his help.
Issue: should we adopt
this draft as a WG item? Conclusion: strong consensus to adopt
it.
Topic: Rendezvous Slides
presented: pres-ietf60-hip-rvs-laganier.pdf Relevant document:
draft-eggert-hip-rvs-00.txt Discussions led by: Julien
Laganier
Issue: should we adopt this draft as a WG item? Conclusion:
strong consensus to adopt it.
Action
Items
- Chairs to update the dates of the milestones.
- Editor of draft-nikander-hip-mm-02.txt to release a new version as a WG
item.
- Editor of draft-nikander-hip-dns-00.txt to release a new version as a WG
item.
- Editor of draft-eggert-hip-rvs-00.txt to release a new version as a WG
item.
Detailed
Discussions
Topic: Base
Spec
No comments from the floor
Topic: Making HIP Multi6 Friendly
Gonzalo: Should we extend the work on
the base spec by 6 months to tailor hip to multi6? Margaret: I have a dilemma. HIP is
experimental. Have all the challenges been solved? How does this fit will
multi6? Gonzalo: This is a
chicken and egg problem. hip cannot mandate something which multi6 cannot
use. Margaret: multi6 is
working with different concerns (e.g., routing table expansion). I am
worried about tying these 2 together. We need more comments. What is the
essential attribute of HIP. Is it to get IPSec working or for creating locator
based agility? Eric
fleischmann: When bob proposed hip everyone was intrigued. Since then
there have been a bunch of incomplete clones in the IETF as hip standardization
as been too slow. It is wrong to share the fate with another WG. Tim Sheperd: The value of hip is that
it can solve a lot of problems. We should finish base spec as planned. People
can write drafts in parallel to extend hip for other purposes. I believe we
should not make changes unless they are exceedingly simple. We can cooperate
with the multi6 design team on applying hip to multi6. Andrew: Issues may be complex to
address. DH is main cause of heavy nature of HIP. It can be simplified. Lookups
and referrals are harder to solve. jak: I like hip for the security
properties. I would not compromise on those. It is better to have a lightweight
subset for people who need it. Bob: Security features are essential.
If multi6 wants a lightweight solution we can leverage the hip work and come up
with a solution (like WIMP). It is not right to couple hip and multi6. Tom: Agrees with the commentors. Keep
hip and multi6 decoupled.
jak: issues with HITs and ip addresses
getting out of sync. Tom:
Yes. There are issues. But I do not know how to get around them jak: Can use CGAs to prevent
accidental miscommunications. Erik: The IP addresses are from the
DNS. So there should be no issues. That is where you want to be reachable. Leave
the address and you cannot be reached.
Topic: Backwards Compatible API
Erik: Does referral based API use
oppurtunistic mode? Miika:
That is natural but is not required. Michael Smith: Want to know about
policy rules for the referral API? Miika: rule that matches an ip address
triggers hip Michael: Can
HITs and IP addresses collide? In oppurtunistic hip we do not know the identity
of the responder. Tom: If you
use DHCP we can have cases where we do not have a HIT/IP addr binding? Pekka (on the phone): Nothing related
to API that changes rules used for IPsec. Difference in API is what the
application sees. Then all firewalling rules and IPsec rules are based on
HIT.
Topic: Mobility and
Multihoming
Tom:
Do we really need multiple SAs for multiple addresses? Should we work on tuning
the replay protection window from RTT estimates? Erik: Worried about TCP issues with
reordering when multiple addresses are used simultaneously. Tom: Cites SCTP. Erik: I want a round robin
scheme. Tom: We can use
multiple SAs, but we DONT HAVE to. Hillary: How does readdressing work
when both the peers move simultaneously? Tom: We have not checked this in
detail. This will be addressed in the policy considerations section (e.g., using
a rendezvous server). Hillary: We need to make this work as
a failover mode.
Topic: DNS
Issues
Julien:
Need more info from people who know DNS well Tom: Is it possible that there are
parallel FQDN->IP and FQDN->HI mappings? Andrew: Have a bunch of A records and
the HIP RRs side by side. This requires least changes to DNS
Topic: Rendezvous
Pekka (thru Lars): Comment from pekka
saying location privacy is a difficult issue and must be moved to HIPRG Gonzalo: I agree Erik: Is there anything preventing
multiple RVSs? Julien: No.
You can have many and the one with the highest preference in DNS is
used Brajesh Kumar: Is RVS
signle point of failure? No
|
Slides
Agenda
Draft-ietf-hip-base-00.txt
Making HIP multi6 friendly
Backwards Compatible API
HIP-mm update
HIP Rendezvous Extensions
HIP DNS Extensions