Subject: [Hipsec] Comments on draft-nikander-hip-mm

From: [email-masked] (Henderson, Thomas R)
Date: Thu Apr 29 15:36:00 2004

> -----Original Message-----
> From: Jonathan Wood [mailto:[email-masked]]=20
> Sent: Wednesday, April 28, 2004 7:29 PM
> To: Pekka Nikander
> Cc: [email-masked]
> Subject: Re: [Hipsec] Comments on draft-nikander-hip-mm
>=20
> I am still having some concerns about how I understand
> the multiple SA scheme to work. Your application
> selects an SA, in which is stored the destination address
> (actually, one or more destination addresses).  In effect,
> you are conflating locators with security associations,
> and naming destinations by the SAs, not the locators.
> This seems harder for applications to deal with, and
> furthermore the conflation seems lossy - if you have a
> group of addresses bound to an SA, there is no guarantee
> that all addresses in the group represent the same path.
> It seems much more logical to me for multipathing
> applications to deal with locators than SAs.
>=20
> Having said that, however, this may just be an issue
> with the language of the proposal - could not an
> implementation have an augmented SPD that allows
> selection of an SA based on the ultimate IP address?
>=20

I guess I don't see the applications selecting SAs, or
that multipathing applications are dealing explicitly with
either locators or SAs.  I still envision transports or some
other element of the system picking the locators or paths,=20
and the system finding the right SA envelope based on the=20
SPD entries.  Maybe this is a terminology issue-- see if
you agree with the below.

In the HIP model, conceptually, packets are sent to other=20
hosts (i.e., to other HITs), which are resolved within the
system to locators.  The system stores a binding between=20
the locators and the HITs.  The system also maintains one or
more SAs for the host-host communications context. =20

In non-HIP IPsec, the outbound SPD is consulted until there=20
is a match on the selectors.  The SPD either points to an
SA bundle, or a new SA is dynamically created.  The SA indicates
the things needed to build the ESP packet, such as SPI.  The HIP=20
model maps to RFC2401 IPsec architecture if you consider the
HIT to be a "system name"-- then the SPD match can be based
on HIT and not the addresses. =20

Without multiple SAs, the SPD matches on HIT.  With multiple
SAs, the SPD perhaps matches on other fields besides HITs,
such as source and destination addresses (i.e., the addresses
are no longer wildcarded).  Therefore, the steps followed
in outbound processing are i) locators are selected=20
(how they are selected if there is some choice is discussed
below), and then ii) either the HIT or the combination of
HIT and addresses are used to find the right SA.

It is the job of the HIP process ("daemon") to manipulate
both the locator/HIT bindings and the SPD/SA entries so that
a) the system can select valid, current locators for the=20
host-host communications context, b) the packet hits the right=20
SA upon exiting the system, and c) SAs are updated as needed=20
(e.g., new SPI or keymat).  REA and NES give the mechanism
to do that (unambiguously, I think).

It is currently out of the draft-mm scope to deal with=20
a) how a system picks locators in a communications context=20
when it has several from which to choose (assume that it picks
the "default" or preferred ones for now), b) how it decides
that a new SA is needed or replay window parameters are=20
manipulated, or c) how to deal with issues such as readdressing
triggering a congestion window response at transport layer,
or adjusting/rediscovering the MTU, etc., when locators change.
=20
Tom

---

From: [email-masked] (Jonathan Wood)
Date: Thu Apr 29 17:59:01 2004

Hi Tom,

On Apr 29, 2004, at 1:26 PM, Henderson, Thomas R wrote:

> other element of the system picking the locators or paths,
> and the system finding the right SA envelope based on the
> In the HIP model, conceptually, packets are sent to other
> system to locators.  The system stores a binding between
> more SAs for the host-host communications context.
>
> In non-HIP IPsec, the outbound SPD is consulted until there
> the things needed to build the ESP packet, such as SPI.  The HIP
> on HIT and not the addresses.
>
> in outbound processing are i) locators are selected
> a) the system can select valid, current locators for the
> host-host communications context, b) the packet hits the right
> SA upon exiting the system, and c) SAs are updated as needed

I agree with all this. I am concerned, however, that we are creating
a solution before we really understand what the problem is. The
portions you leave undefined (i.e. how applications and transport
protocols use the mechanism) are, as you say below, indeed out of
scope of this draft. However, they are, IMHO, what should be
driving the solution. Since we don't understand the problem well,
perhaps it (as well as the solution) would be better discussed in a
research context...

Anyway, there doesn't seem to be support for my point
of view in the WG, so I won't push on it further.

Jon

>
> It is currently out of the draft-mm scope to deal with
> a) how a system picks locators in a communications context
> that a new SA is needed or replay window parameters are