[Hipsec] Preliminary minutes from the Monday HIP RR BOF
pekka.nikander@iki.fi (Pekka Nikander) Fri, 05 March 2004 19:25 UTC
From: pekka.nikander@iki.fi
Date: Fri, 05 Mar 2004 19:25:02 +0000
Subject: [Hipsec] Preliminary minutes from the Monday HIP RR BOF
Message-ID: <AB598C5A-6E78-11D8-9EC7-000393CE1E8C@iki.fi>
X-Date: Fri Mar 5 19:25:02 2004
--Apple-Mail-18--766375674
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
format=flowed
Please find enclosed preliminary minutes from the
HIP RR BOF. Basically, this contains the discussion
transcripts, the rest of the material to be added later.
Please send any corrections ASAP to me. I haven't
had time to process all of the note taker notes yet,
so I may also make changes (mostly additions/names)
by my own. I just wanted to get this out now so
that people may make corrections while they still
may remember what happened. :-)
--Pekka
--Apple-Mail-18--766375674
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
x-unix-mode=0644;
name="ietf59_hiprr_minutes.html"
Content-Disposition: attachment;
filename=ietf59_hiprr_minutes.html
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>IETF-59 HIP Releated Research BOF Summary and Minutes</title>
<meta http-equiv="Content-Language" content="en" />
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<style type="text/css">
body {
margin-left: 10%;
margin-right: 10%;
font-family: sans-serif;
color: black;
background: white;
}
span.sc {
color: red;
}
dd p {
margin: 0;
}
dd ul {
margin: 0;
}
dt {
margin-top: 1em;
margin-left: 1.5em;
}
p.note {
color: green;
}
</style>
</head>
<body bgcolor="white" text="black">
<h1>Host Identity Protocol Related Research BOF (hiprr)</h1>
<p>These are the minutes for the Host Identity Protocol Related
Research BOF (hiprr) meeting, held at IETF-59 on Monday, March 1,
2004, at Seoul Lotte. Thanks to Marcelo Bagnulo, Petri Jokela, Miika
Komu, Julien Lagnier, and Andrew McGregor, for the notes, on which
these minutes are based on.</p>
<div id="menu">
<ul>
<li><a href="#decisions">Decisions made</a></li>
<li><a href="#summary">Summary of the discussions</a></li>
<li><a href="#details">Presentations and discussions</a></li>
</ul>
</div>
<div id="main">
<div id="decisions">
<a name="decisions"></a><h2>Decisions</h2>
<ol>
<li>Should we continue to work on full blown non-HIP supporting proxies?
<p>Yes. Transition mechanisms are an important issue.</p></li>
<li>Should we continue to work on NAT traversal?
<p>Yes, but unclear how. Pressure to work both on solutions that
are friendly to current NAT boxes and on solutions that make NAT
boxes friendly to HIP.</p></li>
<li>Should we continue to work on the Lightweight HIP idea?
<p>Yes (large interest).</p></li>
<li>Should we continue to work on CELP?
<p>Yes (some interest).</p></li>
<li>Should we continue to work on DHT / HIP overlay / ... ideas?
<p>Yes, but unclear where to focus</p></li>
<li>Any additional important areas that we missed?
<p>Applications point of view.</p></li>
</ol>
</div><!-- decisions -->
<div id="summary">
<a name="summary"></a><h2>Summary of discussions</h2>
<p class="note">This summary has been compiled by Pekka Nikander, based on the
discussion minutes, included <a href="#details">below.</a></p>
<h4>Points to pay attention to</h4>
<ul>
<li></li>
</ul>
</div><!-- summary -->
<div id="details">
<a name="details"></a><h2>Presentations and Discussion</h2>
<h3>Research Group background and Status</h3>
<a href="XXX">Slides</a>
<p>As a continuation of the successful HIP BOF in Minneapolis and the
WG chartering discussions that followed, there is a clear need for a
research group that will study the consiquences of HIP or the ID/LOC
split in general. However, ID / locator split major architectural
issue and the IAB wants to investigate it before making a decision.
There is hope that the discussion will be finished shortly, i.e.,
during the week In any case, there will be space for HIP research
group. </p>
<dl>
<dt>Dave Crocker:</dt><dd>What is going on this week about the
id/loc split? The plenary is often not good for resolving issues.</dd>
<dt>Vern Paxon:</dt><dd>The IAB discussion will take place before
the plenary, and results will then be presented there. The plenary
is then a place to see what the community things.</dd>
</dl>
<h3>HIP related research elsewhere</h3>
<a href="XXX">Slides</a>
<p>Pekka briefly discribed related research elswhere, including the
<a href="XXX">NewArch</a>,
<a href="http://www.ambient-networks.org">Ambient Networks</a> and
<a href="http://www.ist-daidalos.org">Daidalos</a> projects.</p>
<dl>
<dt>Vern Paxon and others:</dt><dd>The NewArch project is done.</dd>
<dt>Pekka Nikander:</dt><dd>Ok, but I see the work continuing. We
have to follow what's going on.</dd>
<dt>Kevin Fall:</dt><dd>There has been lots of work on
interoperability over networks that are not Internet
networks. Separation is related to routing, there is SIGCOMM 2003 paper
discussing the area. The delay tolerant networking folks have been
thinking about ID/Loc and have been doing IRTF stuff. See
<a href="http://www.dtnrg.org">www.dtnrg.org</a>. [The SIGCOMM paper
that Kevin mentioned is available through the DTN RG web
pages.]</dd>
</dl>
<h3>HIP proxy / rendezvous broker</h3>
<a href="XXX">Slides</a>
<p>Lars Eggert gave a presentation related to
<a href="http://www.ietf.org/internet-drafts/draft-eggert-hip-rendezvous-00.txt">
draft-eggert-hip-rendezvous-00.txt</a>.</p>
<p>[The comments in the following discussion transcription have been
slightly reordered so that related comments are collected
together.]</p>
<dl>
<dt>Erik Nordmark (clarifying question):</dt><dd>Why does a
rendezvous server need to NAT, why not tunnel?</dd>
<dt>Lars Eggert:</dt><dd>NAT is what the current architectura draft
states. Actually I will propose tunneling a couple of slides
later.</dd>
<dt>Greg Daley:</dt><dd>To me this looks like Mobile IP or like a
VPN tunnel server endpoint. You have a static address, like in MIP,
which acts as the identifier. Would it be worth comparing?</dd>
<dt>Lars Eggert:</dt><dd>The difference really is that this kind of
a relay is needed only if the other party does not understand
HIP.</dd>
<dt>Greg Daley:</dt><dd>It's the same thing with MIP. What is an
advantage for HIP?</dd>
<dt>Elliot Lear:</dt><dd>Could you comment differences with
mipv6?</dd>
<dt>Lars Eggert:</dt><dd>For the HIP-HIP case, a rendezvous can be
anywhere, you don't need to have a fixed home network.</dd>
<dt>James Kempf:</dt><dd>If you renumber the home network, your
identity changes in Mobile, IP but not in HIP.</dd>
<dt>Pekka Nikander:</dt><dd>The proposal it is very similar to MIP
for non-HIP nodes. On the other hand, if we consider only HIP
hosts, there are no restrictions on where you put your rendezvous
server, and you can have multiple rendezvous servers, even
dynamically.</dd>
<dt>Joe Touch:</dt><dd>Are you changing the DNS or modifying the
entries? So the reverse lookups will be ambiguous anyway and lot of
protocols will start failing?</dd>
<dt>Lars Eggert:</dt><dd>There will be additional changes.</dd>
<dt>Rob Austein (clarification):</dt><dd>You do not actually need to
resign the entire zone if a single record is updated via DynDNS.
You can do incremental signing.</dd>
<dt>Miika Komu:</dt><dd> We should concentrate more on the
HIP-to-HIP rendezvous server case. If the peer does not understand
HIP, we fall back to IP.</dd>
<dt>Lars Eggert:</dt><dd>If the IP address in the DNS is the IP address
of a randezvous server, such fallback would not work.</dd>
<dt>Pekka Nikander:</dt><dd>We can't put the rendezvous server
address in the DNS. The WG must rethink this. The WG is supposed
to do the I1/UPDATE only rendezvous server, plus the rendezvous
server DNS record.</dd>
<dt>Kevin Fall:</dt><dd>The terminlogy used here seems to relate to
I3 work. Any comments?</dd>
<dt>Pekka Nikander:</dt><dd>Distributed Hash Tables will come up in
later presentations.</dd>
<dt>Pekka Nikander (chairing):</dt><dd>Is this a topic that should
be studied in the RG? Or should we leave this for the WG?</dd>
<dt>Juergen Quitteck:</dt><dd>This should be a work issue, because
it is important to communicate hip and non hip nodes.</dd>
<dt>Pekka Nikander (chairing):</dt><dd>There seems to be some
interest. I don't see any reason why we can't work on this.</dd>
</dl>
<h3>NAT problem statement</h3>
<a href="XXX">Slides</a>
<p>Juergen Quitteck gave a presentation related to
<a href="http://www.ietf.org/internet-drafts/draft-XXX-00.txt">
draft-XXX-00.txt</a>.</p>
<dl>
<dt>Joe Touch:</dt><dd>Most of the reasons why you say NAT is bad is
that NAT makes everything behind the network look like one host and
this is what you don't want. Most justifications for NAT are
reasons for its brokenness. Stop supporting them.</dd>
<dt>JQ:</dt><dd>NAT is what the users do, you cannot stop them.</dd>
<dt>PN:</dt><dd>If you do a loc/id split, NAT may become less evil,
since you obtain stable id end-to-end. Even if the locators are
changed on the fly, the id is still stable.</dd>
<dt>JQ:</dt><dd>This is not advertising nat, but to address the
problems that NAT pose to HIP. The point is to make HIP and NAT
coexist.</dd>
<dt>PN (clarification):</dt><dd>There are <strong>no</strong>
problems with HIP and checksums in NAT traversal, since in HIP the
pseudo header contains HITs, not IP addresses.</dd>
<dt>PN (comment):</dt><dd>I'd like to mention a couple of problems
with mobility and multihoming. If a mobile host goes to a network
behind a NAT, it already has an association. The NAT has to find out
from the UPDATE packet the new address. The SPI values is also
problem: there may be collisions. Should the SPIs be within or
outside of the signature calculation? DoS does not seem to be a
problem.</dd>
<dt>JQ:</dt><dd>The conflict with using same SPI can be solved with
NATs that have more than one IP address available.</dd>
<dt>Greg Daley:</dt><dd>99% of NATs are unmanaged, so what if they
don't support the hip? Stay in TCP or UDP so you don't rely on NAT
upgrades?</dd>
<dt>Tim Shepard:</dt><dd>I agree. We won't get NATs upgraded. HIP
could be use to get IPv6 for home node behind a NAT. Maybe even in
such a way that v6 is never seen in core network, i.e., use 6to4.
We can't upgrade NAts, but we can ask vendors to support 6to4. This
seems like the right thing.</dd>
<dt>Greg Labovitz:</dt><dd>We are a NAT implementer and we don't
have problem changing NATs.</dd>
<dt>Dave Crocker:</dt><dd>It is easy to get one person to do one
thing, the problem is to get everybody to do it?<br /><br />Why did
I stand up? Well, NATs are not a problem in the net, they are a
problem in the IETF. There are HIP things and then there are other
things that HIP must cope with. NAT is not core business for
HIP.<br /><br /> There are couple of ways to deal with things. If
we wait for NAT boxes to change, we have to wait for a long long
time. If we don't wait, we have to manage difficult things. Thus,
there are multiple ways to solve problems. Short term hacks will
probably be long term (wrong way). Hence, make the ugly thing and
the right thing coexist.</dd>
<dt>Pekka:</dt><dd>I'm not worried about NATs. If HIP happens there
will be an incentive for NAT vendors to support HIP and for users to
upgrade. The boxes are cheap and get cheaper.<br /><br />We have to
make a distinction between two different things:
<ol>
<li>compatibility with current NATs,</li>
<li>HIP allows cross IP realm traversal, which we probably
should not even call NAT</li>
</ol>
You could have multiple IP address realms and let traffic flow
between them, while retaining the 3.5 layer end-to-end connectivity.
We have tried to design the system to make things to work with 3.5
routing. The state in the layer 3.5 routers must be a soft
state.</dd>
<dt>Elliot Lear:</dt><dd>HIP solutions should be long term and
problems solve in the long term ones.</dd>
<dt>Gonzalo Camarillo:</dt><dd>You will never deploy HIP if you need
to update NATs. It is the same problem in SIP. Don't require
modifying NAT.</dd>
<dt>Erik Nordmark:</dt><dd>Should we match HIP and NAT or decouple them
the more possible?</dd>
<dt>LQ:</dt><dd>The question is whether we want to make HIP more NAT
friendly or NATs more HIP friendly.</dd>
</dl>
<h3>Lightweight HIP</h3>
<a href="XXX">Slides</a>
<p>Pekka presented an idea. No questions or comments, but
considerable interest on working on the idea.</p>
<h3>CELP</h3>
<a href="XXX">Slides</a>
<p>Dave Croker gave a presentation related to
<a href="http://www.ietf.org/internet-drafts/draft-crocker-celp-00.txt">
draft-crocker-celp-00.txt</a>.</p>
<dl>
<dt>Pekka (comment):</dt><dd> If we do id/locator split, we get into
situation where we have two sets of different congestion control
variables. Some are related to the path and some to the flow. </dd>
<dt>Dave:</dt><dd> I agree with you. The id-locator combination is
both on the layer 3 and 4. This was not point of this discussion; a
different discussion. If we solve this cleanly, it is good. </dd>
</dl>
<p>Presentation continues with security issues.</p>
<dl>
<dt>Pekka:</dt><dd>Security issues were touched already today. If
you do RR test using IKEv2 or MIPv6, there results are different
from the security point of view. A solution to this may be to add a
a security related granularity parameter. </dd>
<dt>Dave:</dt><dd>We need to figure out the minimum level of
security. I propose naming the IP address pools with domain names,
but this is handwaving that requires work. One of the problems is
that the DNS name -> IP address -> DNS name chain may not
work. There seems to be problems with operation and
administration.</dd>
<dt>Erik Nordmark:</dt><dd>I'm wondering about issues with a shared
pool and multiple users. What is the key for looking up from the
pool? What if we have two users, (two connections), and they give a
different key to retrieve the address from the pool? Or if the
users are attaching different informations to the same key?</dd>
<dt>Dave:</dt><dd>I don't have an answer, needs more
investigation. Multi-address parallel usage would be great.</dd>
<dt>Pekka:</dt><dd>I have an example. Consider using HIP and
SCTP. HIP gets more addresses to the pool (rendezvous servers) than
SCTP.</dd>
<dt>Elliot Lear:</dt><dd>On the use of the domain names. Firstly,
there must be no circular dependencies. Secondly, I was asked to
write a draft for the
<a href="http://www.ietf.org/XXX">multi6</a> WG,
<a href="http://www.ietf.org/internet-drafts/draft-elliot-XX-01.txt">
things to think about</a>.
There are couple of points that are interesting.</dd>
</dl>
<p>Presentation continues.</p>
<dl>
<dt>Dave (question):</dt><dd>Is this interesting? [A few few
hands.]</dd>
<dt>Pekka:</dt><dd>I have a gut feeling: DNS names are not going to
work. You dont put DNS names into the kernel. Looks complicated.
My personal feeling that it is a bad idea.</dd>
<dt>Dave:</dt><dd>Your comments were mild compared to
others. Interesting discussion.</dd>
<dt>Andrew McGregor:</dt><dd>How to you manage the address pool in
the DNS server?? DNS names are pronote to a dispute.</dd>
<dt>Tim Shepard:</dt><dd>Needs cooperation from DNS admins. This is
a showstopper. It is hard to work on a protocol and deploy it if I
can't use it on a network until I get cooperation form the
administrator of the DNS.</dd>
<dt>Dave Crocker:</dt><dd>From the CELP point of view, DNS provides
two different services: lookup service and naming service. We are
not necessarily doing lookups.</dd>
<dt>Erik Nordmark:</dt><dd>Locator pools apply, even if you
introduce new name space.</dd>
<dt>Dave Crocker:</dt><dd>We need an identifier space for pools. We
need some commonality between the users of the pool, in order for
this to be useful.</dd>
<dt>Kevin Fall:</dt><dd>Why not use URI space instead of FQDN?</dd>
<dt>X:</dt><dd>you said: there should be a DB and a key. Key seems
to be DNS names.</dd>
<dt>Dave Crocker:</dt><dd>We need to add a few details before it is
practical.</dd>
<dt>xx:</dt><dd>The CELP acronym is already taken.</dd>
</dl>
<h3>Referrals problem statement</h3>
<a href="XXX">Slides</a>
<p>Pekka Nikander gave a presentation where he tried to clearly state
the referral problem but actually talked more about Distributed Hash
Tables (DHTs). He really should not give that many presentations
during a single RG meeting. [A note to those whose sense of irony is
limited: remember who has compiled these minutes.]</p>
<dl>
<dt>Joe Touch:</dt><dd>I have a little confusion here, why don't we
want to use the DNS?</dd>
<dt>PN:</dt><dd>The HI / HIT name space is flat. You can't use
DNS, as DNS requires hierarchy.</dd>
<dt>JT:</dt><dd>Well, then, make the name space hiearchical.</dd>
<dt>PN:</dt><dd>Earlier version of the HIP drafts contained an
hierarchical name space as an alternative. It was removed for the
sake of simplicity and some other problems. The HIP WG can
certainly add it back if they want to. In the Research Group side,
though, I think that we want to explore the other
possibilities.</dd>
<dt>XX (from Deutche Telecom?):</dt><dd>The carriers may not want to
use DHTs because of the amount of traffic generated.</dd>
<dt>PN:</dt><dd>There may be a misunderstanding here. The way I
envision that we might use DHTs is not really P2P like, or at least
not Napster like P2P. It does not generate any more traffic than
DNS.</dd>
<dt>Rob Austein:</dt><dd>A problme with a DHT is the trust model.
In the DNS you have somone in control of which servers you trust,
and that is not possible in the DHT case.</dd>
<dt>Pekka Nikander:</dt><dd>In DHT you can use several hash keys
and several independent servers.</dd>
<dt>Rob Austein:</dt><dd>So you must trust several strangers
insteas of just one.</dd>
<dt>PN:</dt><dd>The assumption is that you have a strong id check,
so you just need enough replicas to find at least one set of valid
data, i.e., one where the signature is valid. Remember, if we use
DHT with HIP, we have a public key and the strong relation with HIT.
The real problem is whether you get data back or not. To solve
this, you can make ten replicas or so. This is not a perfect
solution, there may be better ones, but is a solution.<br /><br />
But yes, we have two problems: collusion (as I mention in the slide)
and replay of old data. The latter can be solved by always making
more than one lookups, but that is bad from a performance point of
view.</dd>
<dt>PN:</dt><dd>So, basically, what I am saying is that we know how
to make DHTs work in theory but not how in practice.</dd>
<dt>Erik Nordmark:</dt><dd>Practical issues of how well it scales?
In a large network we have many hosts joining and leaving? We would
have a million or more servers. This is different if all internet
uses this than the current DNS use or current DHT research use.</dd>
<dt>Kevin Fall:</dt><dd>All this discussion relates to the new
layer. Maybe i disagree on the issues on the agenda?</dd>
<dt>Pekka Nikander:</dt><dd>We need a mechanism to get IP addresses
from identifiers. We try to get attention from academic research.</dd>
<dt>Kevin Fall:</dt><dd>This is distraction to the reseach group.
There are other communities that are solving these problems. We
should focus on the problems that others are not solving.</dd>
<dt>Pekka Nikander:</dt><dd>how about Erik's comments?</dd>
<dt>Kevin Fall:</dt><dd>Research is going on but you have a
different problem, yes.</dd>
<dt>Thomas Henderson:</dt><dd>Any fresh ideas?</dd>
</dl>
<h3>Using any servers as rendezvous points</h3>
<a href="XXX">Slides</a>
<p>Tim Shepard described his idea of using any servers as rendezvous
servers.</p>
<dl>
<dt>Tim Shepard:</dt><dd>About HIP rendezvous issues. I'd like to
have a system that doesn't use DNS at all, where end points
recognize each other without using dns. You just introduce each
other once and then they know each other. Server mobility is easy
because the server remains fixes simultaneous movement: only one of
the moving host has to maintain a association with the rvs
could all hip nodes act as relays?</dd>
<dt>Elliot Lear:</dt><dd>That was a great bar conversation. Really
good questions. May I disagree: it is ok to use DNS, its ok to fail
if the resouce is not present. First question: In simultaneous
movement, what is the tolerable period to have stale info? Second
question: In moving from one location to another, how do you
introduce the routing system, leave info in everywhere you go?</dd>
<dt>James Kempf:</dt><dd>Two nodes moving at the same time. You lose
the update. When a node moves it tells the old router so that the
traffic can flows to the new location. So we can come up with a
local link fixed routing protocol (for HIP, MIP...)<br /><br /> For
VoIP, the maximum is 40 ms dropout period. This figure also works
for HIP. This work has not gone anywhere due to non-interest.</dd>
<dt>Tim Shepard:</dt><dd>This is this same as Eliot mentioned.</dd>
<dt>James Kempf:</dt><dd>Yes, approximately. Router and node has to
find out the movement. 40 ms is allowed, due to voip apps.</dd>
<dt>Tim Shepard:</dt><dd>May be. However, my basic observation is
that if you have implemented HIP, you are only few lines [of code]
away from a [I1-only] rendezvous server.</dd>
<dt>Erik Nordmark:</dt><dd>If every node acts as a relay wouldn't
this enable new attacks, is it worse tat than ipv4 today? Consider
open SMTP relays today. Here you have strong identity. You have to
tell where they are coming from to get them shut up if needed. You
can hide your IP address. If you have IP address, you can tell the ISP
that this guy must be "closed".</dd>
<dt>Kevin Fall:</dt><dd>This looks awfully lot like i3. Refrasing,
is is better to have an infra with storage capability, or is it
better to be more active.</dd>
<dt>Pekka Nikander:</dt><dd>This is one very good question. This is
the third independent time that I hear I3 and HIP in same sentence.
I am starting to wonder why</dd>
<dt>X:</dt><dd>HIP identifiers like ethernet addresses from the
forwarding point of view. You use the identifier only
on the last part. Not so vulnerable.</dd>
<dt>Tim Shepard:</dt><dd>I dont really understand the question. HIP
ids can be proved to be owned.</dd>
<dt>X:</dt><dd>Different thing. It is just equivalent to that
point.</dd>
<dt>Tim Shepard:</dt><dd>Are you saying that we should take only
part of the HIT as the id. Possiblity of collisions gets greater. I
don't know how to solve that.</dd>
</dl>
<h3>Open mike</h3>
<dl>
<dt>Pekka:</dt><dd>People are working on the DHT problems elsewhere
so we don't have to take so much effort on those things. Concentrate
on understanding HIP effect to the Internet.</dd>
<dt><span><a href="#stevekempf">Steve Kempf:</a></span></dt>
<dd>What's impact on applications?</dd>
<dt>Erik Nordmark:</dt><dd>Another thing, how IDs show up at the
application layer. Does this change applications? Does this change
the way to use applications?</dd>
<dt>Pekka Nikander:</dt><dd>One of the questions is that we have an
aulli mailing list, basically dead at the moment. Which is the right
forum to look at application area?<br /><br />Maybe we should have a
sub research group for application issues. I don't know how to
organize this kind of thing.</dd>
<dt>Erik Nordmark:</dt><dd>Are there people in the room that
understand application level identifiers? [No hands]</dd>
<dt>XX:</dt><dd>This is a difficult question.</dd>
<dt>Joe Touch:</dt><dd> I can take applications that use ip
addressses in different ways. They will suffer from using HITs. Who
understands apps. use of addresses? Many bizzarre things out there.
Is non-hip host talking to non-hip app on hip enabled device a problem?</dd>
<dt>Erik Nordmark:</dt><dd>No idea, but does existence of HIP
namespace change things in interesting ways? What other kinds of
IDs do applications use?</dd>
<dt>XX:</dt><dd>There is also a body existing work related to these
things. There are surveys about these issues. Have been surveys of
app protocol use of IP addresses.</dd>
<dt>Keving fall:</dt><dd> Are these right things? Semantics, routing
system, what layer routing system it relates to, hierarchical. Lot
of things to cope with.</dd>
<dt>Elliot Lear:</dt><dd> NSRP draft looks at some of this. Remember
also the draft mentioned earlier with the open questions.</dd>
<dt>Pekka Nikander:</dt><dd>There are some answers in HIP
architecture draft. Maybe they are not sufficient. The draft was in
RFC Editor queue, but it is now back for editing. Please review the
architectural draft, needs to be stable as soon as possible.</dd>
<dt>Pekka Nikander (chairing):</dt><dd>No more comments? Seems to be
so that we have many of the correct problems. The apps level
identifiers stuff needs to thought in more detail. We Need help
from the apps people. </dd>
</dl>
</div>
<!-- details -->
<a name="stevekempf"></a>
<p id="stevekempf">Footnote: I have no idea who Steve Kempf is, but
one of the note takers marked this particular speaker as "Steve"
while the other one attributed "Kempf". The other's didn't have a
name recorded, or not even the comment recorded.</p>
</div><!-- main -->
<hr />
<div class="footer">
<p class="validator">
<a href="http://validator.w3.org/check/referer">
<img src="http://www.w3.org/Icons/valid-xhtml10"
border="0"
alt="Valid XHTML 1.0!"
height="31" width="88" /></a>
</p>
<p class="copyright">
Copyright
 ©  2004
<a href="http://www.ietf.org">Internet Engineering Task Force</a>.
</p>
</div>
</body>
</html>
--Apple-Mail-18--766375674--
- [Hipsec] Preliminary minutes from the Monday HIP … Pekka Nikander