Subject: [Hipsec] A HIP WG charter proposal

From: [email-masked] (Pekka Nikander)
Date: Fri Sep 19 03:11:00 2003

Folks,

Please find below my initial charter proposal for a HIP WG.
I wish that we would have a lively discussion on the list,
and consider alternativities.  On the other hand, I hope
that people remain as civilized as they always have been
on this list, and that all expressed opinions are well
backed with clearly explained thoughts.

In particular, I think that is debatable whether the WG
should try to standardize any changes to the IPsec ESP,
as the charter proposes.

--Pekka Nikander

Host Identity Protocol (HIP)

Chair(s):
TBD.

Internet Area Director(s):

Thomas Narten <[email-masked]>
Margaret Wasserman <[email-masked]>

Internet Area Advisor:
TBD.

Security Area Liason:
TBD.

Mailing Lists:

Send mail to: [email-masked]
With a subject line: subscribe
List archive: http://honor.trusecure.com/pipermail/hipsec/

(This is a new list that has replaced the old list hosted at
  lists.freeswan.org.  It was necessary to move to a new list
  due to technical problems with the old one.)

Description of Working Group:

Host Identity Protocol (HIP) proposes a solution for separating
the end-point identifier and locator roles of IP addresses.  It
introduces a new Host Identity (HI) name space, based on self
generated public keys.  In particular, it specifies a protocol
to permit IPv6 and IPv4 hosts to identify each other based on
the public keys, to establish a pair of host-to-host ESP security
associations using these public keys, and to run both IPv4 and
IPv6 applications side-by-side independent of the underlying
type of connectivity.  It also allows many IPv4 applications to
communicate directly with IPv6 applications, and vice versa.

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

    draft-moskowitz-hip-arch-03.txt  and
    draft-moskowitz-hip-07.txt (soon -08.txt)

Both of these documents are relatively mature, and planned to be
fairly soon submitted to the IESG for consideration as
Experimental RFCs.  There are four existing, 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 and a new piece of infrastructure, called the
HIP rendezvous server of the HIP proxy.

+-------------------------------------------------------------+
| The purpose of this Working Group is to define the required |
| infrastructure elements that are needed for HIP to be       |
| experimented in a wide scale.                               |
+-------------------------------------------------------------+

In particular, the objective of this working group is to complete
the DNS, mobility, multi-homing, and NAT traversal work on HIP,
and produce Experimental RFCs for these.  If necessary, the WG
can also revise the base HIP protocol specification, but only if
the changes do not substantically increase the complexity of the
base protocol.

Additionally, the working group aims to standardize, together
with the IPsec Working Group, the necessary hooks that would
allow HIP to utilize unmodified IPsec ESP.  One particular way of
implementing the small changes required to IPsec ESP has been
defined in a separate draft:

    draft-nikander-esp-beet-mode-00.txt (to be issued)

The following are charter items for the working group:

0) If the architecture and base protocol specifications have not
    been submitted to the IESG by the time the WG is formally
    created, complete the specifications and submit them to the
    IESG.

1) Complete the basic mobility and multi-homing support for HIP.

    This work will use draft-nikander-hip-mm-00.txt as a starting
    point.  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.

2) Define DNS interactions, including how to store HIP Host
    Identifiers into the DNS.

3) Define NAT traversal for HIP.

    The NAT traversal must work with mobile and multi-homed HIP
    hosts.  The mechanism MAY require changes to existing NAT
    boxes.

4) Define a HIP rendezvous and proxy mechanism.

    A HIP rendezvous mechanism is needed to provide initial
    connectivity with fast moving HIP hosts, and to allow
    simultaneously moving hosts to find each other after
    con-current movements.

    Additionally, HIP hosts are currently able to talk talk to
    non-HIP hosts using standard IPv6 or IPv4, including MIPv6 or
    MIPv4.  However, if they do so, the HIP hosts do not benefit
    from the mobility and multi-homing aspects of HIP.  A proxy
    would allow a HIP host to talk to a non-HIP host, but still
    use HIP mobility.

5) Optionally, define a mechanism that allows any Host Identifier
    to be as a seach key to find a DNS name and/or an IP address.
    Such a mechanism could be based on Distributed Hash Tables.

6) If needed to complete any of the items above, revise the base
    protocol specification.  If any such revisions are needed,
    care must be taken not to unnecessarily increase the
    complexity of the base protocol.

The Working Group bases all the work on the base HIP protocol
specifications (as defined above).

Specifically out of scope is comparison of HIP to existing or
other proposed IP based mobility, multi-homing, security, or NAT
traversal solutions.  This does *not* mean that such comparison
should not be made (indeed, such comparisons would be very
valuable), but that they are out of the scope of the working
group, and should not be discussed at the working group mailing
list.  Announcements of any completed works in those areas are
acceptable.

Goals and Milestones:

Nov 03	  Complete draft-moskowitz-hip-arch and
     	  draft-moskowitz-hip and submit them to the IESG to be
     	  considered as Experimental.

Nov 03	  First version of draft-ietf-hip-mm-00.txt, using
     	  draft-nikander-hip-mm-00.txt as a starting point.

Nov 03    First version of draft-ietf-hip-esp-beet-00.txt, using
     	  draft-nikander-esp-beet-mode-00.txt as a starting point.

Dec 03	  First version of draft-ietf-hip-dns-00.txt.

Jan 04	  First version of draft-ietf-hip-nat-00.txt.

Jan 04    Combined HIP and IPsec WG LC on draft-ietf-hip-esp-beet-XX.txt

Feb 04    First version of draft-ietf-hip-rendezvous-00.txt

Mar 04    Submit draft-ietf-hip-esp-beet-XX.txt to the IESG for
     	  Standards Track.

Mar 04	  WG LC on draft-ietf-hip-dns-XX.txt.

Apr 04	  WG LC on draft-ietf-hip-mm-XX.txt and
     	  draft-ietf-hip-nat-XX.txt.

May 04	  Submit draft-ietf-hip-dns-XX.txt to IESG for Experimental.

Jun 04 	  Submit draft-ietf-hip-mm-XX.txt and
     	  draft-ietf-hip-nat-XX.txt to IESG for Experimental.

Jul 04    WC LC on draft-ietf-hip-rendezvous-XX.txt.

Sep 04    Submit draft-ietf-hip-rendezvous-XX.txt to IESG
           for Experimental.

Nov 04	  Close or recharter the WG.

Current Internet-Drafts:

draft-moskowitz-hip-arch-03.txt
draft-moskowitz-hip-07.txt
draft-nikander-hip-mm-00.txt

Proposed new WG items:

draft-ietf-hip-mm-XX.txt
draft-ietf-hip-esp-beet-XX.txt
draft-ietf-hip-dns-XX.txt
draft-ietf-hip-nat-XX.txt
draft-ietf-hip-rendezvous-XX.txt

---

From: [email-masked] (Scott W Brim)
Date: Sun Sep 21 11:33:01 2003

>    draft-nikander-esp-beet-mode-00.txt (to be issued)

I would not put this in.  It's a good idea, but putting it in the
charter creates a dependency on another working group, and expands the
potential scope to the point where arguments about scope might lead to
nothing ever happening.  Revise the charter to add it later, if we're
successful with the main tasks.

..swb

---

From: [email-masked] (Pekka Nikander)
Date: Tue Sep 23 10:20:01 2003

> successful with the main tasks.

Well, if we could get a small change in to ESP, it would be
possible to implement HIP completely in the user level, and
use kernel level ESP.  As the state is now, it is possible
to implement HIP in the user level, but it requires a user
level ESP implementation as well.  In a host that supports
IPsec, this results in two different ESP implementations
User level ESP also requires that all packets flow through
the user space, while one integrated with kernel level ESP
allows the packets to be processed in kernel up to the API
level.

Another difference would be in host protection.  The
functionality proposed in the draft could also be implemented
without modifying ESP, using an other kernel component.
A hostNAT (a la Bellovin), if you will.  However, such a
two-part implementation would be harder to configure,
leading to easier and probably more common configuration
mistakes.

Hence, from an implementation, performance, and security point
of view, the proposed small change to ESP would be very good.
The draft is also written to be more generic, and not solely
HIP specific.  I believe that it would be good for Mobile IP, too.

An early version of the draft is available at
http://www.tml.hut.fi/~pnr/BEET/draft-nikander-esp-beet-mode-00.txt

I will submit it as soon as I get an initial version of the
security considerations section written, basically pointing
out the problems with a two element configuration vs. integrated
implementation configuration.

--Pekka

---

From: [email-masked] (Michael Richardson)
Date: Tue Sep 23 10:48:01 2003

-----BEGIN PGP SIGNED MESSAGE-----

I read beet mode awhile ago.

It seems that beet mode is a new kind of tunnel mode, and the
FreeS/WAN effort would be supportive of it. It should be easy to 
negotiate in IKE (even v1), and shouldn't really be that hard to
code.

As I understand it, but maybe I'm wrong, beet mode can be replaced
with tunnel mode, but there are packet size and PMTU issues that 
come up.

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [