Subject: [Hipsec] Re: draft-nikander-hip-mm-01.txt

From: [email-masked] (Henderson, Thomas R)
Date: Wed Jan 21 15:12:01 2004

I have some questions regarding the mobility draft.  Some=20
things have changed considerably since the time that REA was in
the base spec, and I don't understand the motivation for many of=20
these changes, and am wondering whether they are necessary.

Here are some fundamental questions:

i) we used to have a REA that updated the (primary) destination
address to use for the HIP SA.  This did not cause rekeying or
new SPI generation, nor did it require a return routability
check. REA could be authenticated based on signature.  We now
seem to have drifted far from this basic approach. =20

Why does readdressing require return routability check (what
is the attack?) and new SPI generation?

Asked another way, what is it about a simple REA/REA-ACK=20
handshake, and modification of the preferred outbound IP address
without otherwise changing the SA, that is undesirable?=20

ii) There is an additional level of abstraction introduced called=20
an "interface."  This is a new architectural component-- IPsec
SAs are now bound to interfaces rather than to hosts, and more
than one SA may be active between hosts.  This is a departure=20
from the premise adopted in the base specification that HIP=20
supports only one SA between hosts.  For HIP to support more=20
than one SA between any two hosts requires some way to index=20
SAs within the context of the HIP association-- this is how I=20
view the logical "interface" concept introduced in this draft. =20
But I question whether it is necessary, and if it is, shouldn't=20
it be in the base spec and in the architecture doc?

(also, the overloading of the term "interface" may cause confusion=20
because most people have rather concrete conceptions of what an
interface is.) =20

iii) as for multihoming, the architecture is unclear.  How does
this play with SCTP dynamic address reconfiguration, which=20
looks similar to me (allows multiple addresses to be in use,
for purposes of recovery via alternate path-- and in the future,=20
load balancing?-- and allows one address to be "primary"). =20

Are both needed?  Should HIP mechanism replace transport
level multi-address handling?  Should more work on the SLAP
concept be done?  Note also that if congestion control=20
continues to live in the transport protocol above
HIP, it is not appropriate to hide the presence of multiple
possible source and destination addresses (multiple paths)
from transport, so it is probably not appropriate to infer
that transport level connections need not have any notion
of underlying IP addresses anymore with HIP. =20

This also gets into the question of whether it is HIP's job
to determine which of possible addresses should be primary.

Maybe the approach, suggested by Marcelo in a previous post,
towards specifying only a basic mechanism for mobility (change
primary destination address to use for IPsec transport
layer outer header) is the prudent approach for now, with
more comprehensive multihoming (and perhaps mobility
extensions) coming later.

minor comments:

- Sec 5-- insulated -> decoupled

- end of section 5:  "space specification" -> "base specification"

- Section 5, I would say "without causing SA reestablishment" instead=20
of  "without causing loss of connectivity."

- Mention the double jump problem at the end of section 1 as an
issue that this draft does not discuss?

- Sending REA in R1 seems to lead to same issues we have been=20
discussing with respect to using R1 for HIP loss of state=20

---

From: [email-masked] (Julien Laganier)
Date: Thu Jan 22 06:03:01 2004

On Wednesday 21 January 2004 21:43, Henderson, Thomas R wrote:
> I have some questions regarding the mobility draft.  Some
> the base spec, and I don't understand the motivation for many of
> seem to have drifted far from this basic approach.
>

RR check is required to avoid DoS on third parties (attacker asks a 
server to send huge stream of packets, then send REA to the server 
with the IP address of the attack's target). The new SPI generation 
is used as a cookie in the RR check, thus avoiding a new parameter.

> Asked another way, what is it about a simple REA/REA-ACK
> without otherwise changing the SA, that is undesirable?

Doing RR check with REA/REA-ACK seems to require another packet for 
carrying cookie:
--> REA
<-- REA-ACK|cookie
--> REA-CONF|cookie

> ii) There is an additional level of abstraction introduced called
> than one SA may be active between hosts.  This is a departure
> from the premise adopted in the base specification that HIP
> supports only one SA between hosts.  For HIP to support more
> than one SA between any two hosts requires some way to index
> SAs within the context of the HIP association-- this is how I
> view the logical "interface" concept introduced in this draft.
> But I question whether it is necessary, and if it is, shouldn't

My understanding is that per logical interface SAs abstract IPsec from 
the different characteristics of interfaces. Also it might be useful 
for ULPs doing flow control to be exposed to the concept of 
"interface", for instance when doing handover from one interface to 
another, flow control algorithms can be resetted.

> (also, the overloading of the term "interface" may cause confusion
> interface is.)

Why not call them "virtual interfaces" as their MIP and IPsec 
counterparts?

> this play with SCTP dynamic address reconfiguration, which
> for purposes of recovery via alternate path-- and in the future,
> load balancing?-- and allows one address to be "primary").
>
> level multi-address handling?

It seems to me that HIP implements sort of "network level" 
multi-adressing, so I guess it's redundant with transport level 
support, and both shouldn't be used simultaneously. 

>  Should more work on the SLAP
> concept be done?  Note also that if congestion control
> of underlying IP addresses anymore with HIP.

While the logical interfaces is exposed to ULPs, multiple src/dst can 
be hiden without preventing flow control if each logical interface is 
laid on "apparented" interfaces (by apparented, I want to denote 
similarity in bandwith, routing path, link quality, like two ethernet 
connected on the same router, or two GPRS with similar ISPs)

> to determine which of possible addresses should be primary.

It makes sense to me to factor this functionnality as down in the 
stack as possible. As it doesn't seems to be IP's job, I tend to 
think that it is HIP's one.

Thanks,

--julien

---

From: [email-masked] (marcelo bagnulo)
Date: Thu Jan 22 06:21:01 2004

Hi Thomas,

> Here are some fundamental questions:

I include my opinions about htis questions FWIW

> is the attack?)

As far as i understand, this is very important in order to prevent flooding
attacks.

The attack would be the following:

attacker A
streaming server S that generates very big load
victim S

A contacts S and ask for a heavy data flow
S starts sending the load to A
A then redirects the flow to V, he can do it becuase he can authenticate the
request
V is flooded with the stream

In order to prevent this, you need to verify that address V really belongs
to A, which in this case is not true, you can address this by doin a RR
check

For a much better  explanation about this attack, please check
draft-nikander-mobileip-v6-ro-sec-02.txt

> and new SPI generation?

I really don't have an opinion about the term interface, but i think that a
introcuding a way to group multiple addresses and not all of them as in a
node it would be useful. I think there are possible scenarios where you want
that a certain communication can use a set of addresses but not all the
addresses available in the host. This may be because using different
addresses may have different properties.

For instance, if you consider a multihomed site, that obtains addresses from
each of its providers, and you also assume that some ingress filtering is in
place, using a certain address implies selecting a certain provider.
So you have 3 addresses and 3 providers.
Perhaps you want to use only two of these isps (that is only two of these
addresses) for a certain type of communications.
As i understand what is being proposed, you could just play with the
interface concept and only allow such communications to use a certain
interface that groups only those selected addresses. But perhaps i am
misunderstanding something here....

> of underlying IP addresses anymore with HIP.

Very good questions.

My view is that those different mechanism complement each other.

LEt me ask you a question from a different perspective, what happens with
regular TCP communications, or with UDP communications?

Enabling multihoming and mobility mechanisms at the HIP layer enables these
single address tranpsort layer to benefit from multiaddresssing.

So fully agree with you, if the transport layer is aware of the multiple
addresses and knows how to handle them, so let him do it.

But if the transport layer don't know how to deal with this, handling
multiple addresses at the HIP layer IMHO clearly provides a benefit.

agree?

> extensions) coming later.

I think tha defining extensions to add and remove addresses are important
for multiple problems, such as mobility and multihoming.
Those extensions are common to all these problems, so that what i think that
they should be defined in a separate doc independeltlly of multihoming or
mobility. This is also becasue only this extension don't really address
these problems completelly, they are just a part of the solution.

Then separate docs addressing the mobility and the multihoming problems
would be required, (i think the Pekka is working on them, especially the
multihoming draft)

regards, marcelo

> - Section 5, I would say "without causing SA reestablishment" instead
> - Sending REA in R1 seems to lead to same issues we have been
> discussing with respect to using R1 for HIP loss of state
>
>
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: [email-masked] (marcelo bagnulo)
Date: Thu Jan 22 07:30:01 2004

Hi Thomas,

attacker A

Very good questions.

agree?

regards, marcelo

---

From: [email-masked] (Pekka Nikander)
Date: Fri Jan 23 13:47:01 2004

Tom, Julien and Marcelo,

> these changes, and am wondering whether they are necessary.

Very good question.  I will try to give some motivation below.
However, it is far from clear whether -01 is any better than
the -00 mechanism.  It was mostly an experiment to see if
it would be possible to make REA a parameter instead of
a separate packet.  I don't know whether it adds or reduces
semantic complexity.  That is something that we need to
discuss.

> seem to have drifted far from this basic approach.

Well, REA still still updates the primary destination address.
I will add the option of being able to use REA without RR,
as I already wrote.

I'm not sure if the tight integration with NES, as is done
in -01, is the right way of performing RR.  I wanted to see
whether it is possible at all, and what are the resulting
semantics.

I think this was a good exercise, even if we decided to
abandon it.  It showed that we really need HIP
association specific sequence numbers to prevent replay
attacks.  We probably would have noticed that anyway,
but probably much later.

> is the attack?) and new SPI generation?

Return routability check was discussed already.
SPI generation is a side effect of integrating with NES.

But there is more.  When you readdress, your may temporarily
loose your connectivity.  This may lead one end
to send lots of packets that get dropped, and that may
eventually lead to a situation where the IPsec SAs replay
protection windows get out of sync.

Secondly, if you move to a network which is behind a NAT
box, you have to inform the NAT box about your SPIs, or
otherwise the NAT box is not able to map the SPIs to your
IP address.

> without otherwise changing the SA, that is undesirable?

Considering the going-behind-a-NAT-box case, there were
basically two alternatives.  One would be to include
both SPIs (incoming and outgoing) to the REA, allowing
the NAT box to learn the mappings from a single REA.
However, that leads to a potential vulnerability, where
the sender of the REA lies about the the SPI of the
direction where it doesn't have control.  It also
leads to complications if there are cascading NATs.

The other alternative is the one I chose, changing the
SPI in both directions in separate packets.

Now, Tom, would it suffice to you if the spec allowed one
to have the old SPI and new SPI identical, in which
case there would be no drawing of new keying material
nor other changes in the SA?

> an "interface."

The name "interface" was a poor choice.  I've already now
changed it to "address group", more to indicate that it is
a logical concept.

The basic reason for this concept is that if you have a
multi-homed host with different QoS characteristics on
the different interfaces, you need different SAs or
otherwise some of your packets will arrive outside of the replay
protection window.

I have no desire to use them for something else.  Some
other people may have, though.  I don't see any reason
why they couldn't be used, provided a suitable local policy.
But that would be a different extension from REA, I think.

> For HIP to support more
> SAs within the context of the HIP association.

Well, you need that in the kernel, yes.  But as far as I can
see, you don't need to expose that to most applications.  (Some
applications may want to know, through some new API.)

> it be in the base spec and in the architecture doc?

I see it as an extension, extending the logical concept of a
single SA just over different paths with different latencies
and bandwidths.  Due to replay protection you just can't use
a single SA any more.  On the other hand, all of the parallel
SAs have the same policy, and the kernel may select which SA
is used, based on the current multi-homing situation.

> load balancing?-- and allows one address to be "primary").

This is a good question to be discussed at the multi6 wg.

> Are both needed?

No.

> Should HIP mechanism replace transport level multi-address
> handling?

I think so, but apparently a number of people disagree.

> Should more work on the SLAP concept be done?

Definitely, IMHO.  But maybe slightly later.

> Note also that if congestion control

We are envisioning to implement this by having different
set of transport QoS estimate data structures, and having
the HIP layer to change the structure "underneath".  In
that way you "change TCPs memory" without TCP being aware
of that.  However, that is more thought as an implementation
hack allowing quick prototyping that the proper way of
doing it.

> to determine which of possible addresses should be primary.

Indeed.

> extensions) coming later.

Hmm.  Given the current situation in multi6, I think that
the kind of proposal I wrote is valuable.  Indeed, I was
asked to write a HIP based multi-homing spec.  The two drafts,
   draft-nikander-hip-mm-01.txt and
   draft-nikander-multi6-hip-00.txt,
form that now.  (I will try to update both before the final
Seoul deadline.)

> minor comments:

I'll address these in -02.  Thanks.

My current plan is to issue a -02 based on -01, with these
minor comments and more text based on this discussion.
In parallel, we can discuss whether the -01 approach is any
better than -00 approach.  Apparently -01 is still not the
"right" way.  More thinking and experimenting is needed.

--Pekka Nikander