[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: HIP BOF Heads-up
How does this potentially/possibly conflict/complement with
the open IAB Address Architecture Meeting that the IAB had at
the Vienna IETF and where the follow up was/is going to be
a mailing list for discussion (my understanding is that
IAB is close to announceing the list).
Maybe we should check with IAB too?
Actually, in the past (Margaret of course does/cannot know))
we used to send BOF related queries/ballons to iesg and iab
lists. I propose, that Margaret does so with this one too!
Thanks,
Bert
> -----Original Message-----
> From: Margaret.Wasserman@nokia.com
> [mailto:Margaret.Wasserman@nokia.com]
> Sent: dinsdag 30 september 2003 23:12
> To: iesg@ietf.org
> Subject: HIP BOF Heads-up
>
>
>
> Hi All,
>
> The HIP folks have asked for a BOF in Minneapolis where they
> hope to discuss the formation of a WG. Their proposed charter
> is attached below.
>
> Thomas and I are inclined to approve this BOF. However, we
> know that there have been some concerns raised about this work
> in the past, particularly in the security area... Do folks
> have any thoughts on whether or not to approve this BOF?
> Initial thoughts on the proposed WG charter?
>
> Margaret
>
>
> Host Identity Protocol (HIP)
>
> Chair(s):
> TBD.
>
> Internet Area Director(s):
>
> Thomas Narten <narten@us.ibm.com>
> Margaret Wasserman <mrw@windriver.com>
>
> Internet Area Advisor:
> TBD.
>
> Security Area Liason:
> TBD.
>
> Mailing Lists:
>
> Send mail to: hipsec-request@honor.trusecure.com
> With a subject line: subscribe
> List archive: http://honor.trusecure.com/pipermail/hipsec/
>
> 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
>
>