Subject: [Hipsec] Combining SLAP and HIP?

From: [email-masked] (Pekka Nikander)
Date: Wed Nov 19 06:19:01 2003

This is a multi-part message in MIME format.
--------------070401020306010005040906
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

The SLAP approach is getting pretty favourable comments at
the multi6 mailing list.  Personally, I think that it
is a great idea.  However, I also think that the HIP way
of introducing cryptographic end-point identifiers is
a great idea.  Now, the question prevails if we can
somehow integrate these?  For example, could HIP work as
a control protocol for SLAP?  May TCP could use HITs,
STCP use SLAP directly, etc?

Any ideas?  (Before thinking too much, it is probably
a good idea to read the rest of the messages on this
at the multi6 mailing list.)

--Pekka Nikander

--------------070401020306010005040906
Content-Type: message/rfc822;
 name="Shared Locator Address Pool (SLAP) protocol proposal"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Shared Locator Address Pool (SLAP) protocol proposal"

Date: Sat, 15 Nov 2003 08:45:55 -0800
From: Dave Crocker <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Shared Locator Address Pool (SLAP) protocol proposal
Sender: [email-masked]

Folks,

A fundamental advantage that transport-based locator-pool schemes
(SCTP, DCCP, TCP-MH) have over wedge-layer approaches (HIP, LIN6,
MAST, MIP) is that they can multiplex the control exchange in with
data traffic, potentially saving on number of packets. Wedge-layer
approaches are forced to have an explicit, separate exchange. MAST
makes this asynchronous from the data exchange that uses the locator
pool; this avoid startup delay. However the basic cost of the exchange
remains. If a host must do this exchange with every other host it
talks to, the aggregate overhead is high.

Deferring use of the mechanism, as Pekka S. described, is one way to
reduce such traffic.

Wouldn't it be nice if it were possible to have the "enhanced"
transport services share their lower-cost largesse with the
wedge-layer schemes?

So, here's the thought:

1. An endpoint runs Locator Pools (LP) as a resource shared among different
consumer services at the endpoint -- eg, a wedge layer service and an enhanced
transport service -- potentially with multiple maintainers. (Yes, the latter
raises a concern about synchronization, but let's ignore that minor detail,
for now.) LPs might vary in their granularity.  Bigger grains makes it
more likely that the pool will be shared.  A pool that is the finest
grain (Connection) can't be shared, of course.

2. A common Shared Locator Address Pool (SLAP) protocol is used by the
different maintenance services, over different communication channels
(eg, multiplexed on the transport channel, versus over an independent
control channel). The maintenance services also might use different
"configurations", such as peer-to-peer exchange, versus third-party
agent mediation.

3. Enhanced transport services access the pool directly. Legacy
transport services access the pool via the much-vaunted IP wedge layer
service. If an enhanced transport is one of the participants, then
there really is no need for a wedge-layer service to conduct an
exchange. This saves packets.

The obvious direction this idea leads is towards an effort to produce
a common protocol.  Clearly it should include the locator
"characterization" attribute-signalling capability that Erik suggested.

Anyone from the various camps interested in discussing such an effort?

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

--------------070401020306010005040906--

---

From: [email-masked] (Derek Fawcus)
Date: Wed Nov 19 09:37:01 2003

> at the multi6 mailing list.)

Yeah read part of it,  but not all of it.  However I'll comment anyway...

It rather depends upon the usage model.

As it is there are only usually two situations in which I'm communicating
with a lot of different hosts.

The first is DNS resolution,  the second web browsing.

Now for DNS resolution,  often (i.e. when at work),  I'm forced to use
a particular resolving server.  So I only talk to that one host.  It's
only at home,  that my DNS resolver can contact all and sundry.

However I don't think HIP maps well to that sort of problem (not much
does,  DNSSEC - a unresolved problem).

The second situation - web browsing is more interesting.  However,  most
(if not all) of this is publishing,  so there is no interest in privacy,
i.e. crypto is not an issue.  Additionally,  the connections tend not
to be long lives (compared to expected movements),  so again it would
appear to be uninteresting wrt HIP.

The only bit with any interest is potentially purchasing (https),  but even
there the crypto is pointless,  as any 'security' is provided by being able
to repudiate credit card transactions.

So,  the situations where I see these facilities being used,  are for a
few long lived connections.  And for these,  the delay in setting up the
connection is inconsequental.

DF

---

From: [email-masked] (Pekka Nikander)
Date: Wed Nov 19 10:48:00 2003

Derek,

> ...  DNS resolution,  the second web browsing.

I don't see how either SLAP or HIP would be applicable to
either DNS resolution or web browsing.  For DNS resolution
you want to have application level multi-homing for obvious
reasons, and for web browsing you probably want to share
load between servers instead of having multi-homed servers.

Hence, I don't understand what's your point.  Are you saying
that both HIP and multi6 are useless?  If so, I do understand
what you are saying but I don't understand why you are saying
that.  If not, I have to admit that I am totally confused.

--Pekka Nikander