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

Hi Thomas,

> Here are some fundamental questions:

I include my opinions about htis questions FWIW

>
> 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.
>
> Why does readdressing require return routability check (what
> 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?
>
> Asked another way, what is it about a simple REA/REA-ACK
> handshake, and modification of the preferred outbound IP address
> without otherwise changing the SA, that is undesirable?
>
> ii) There is an additional level of abstraction introduced called
> 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
> 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
> it be in the base spec and in the architecture doc?
>
> (also, the overloading of the term "interface" may cause confusion
> because most people have rather concrete conceptions of what an
> interface is.)
>

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....

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

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?

>
> 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.
>

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

> minor comments:
>
> - Sec 5-- insulated -> decoupled
>
> - end of section 5:  "space specification" -> "base specification"
>
> - Section 5, I would say "without causing SA reestablishment" instead
> 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
> discussing with respect to using R1 for HIP loss of state
>
>
> _______________________________________________
> Hipsec mailing list
> Hipsec@honor.trusecure.com
> http://honor.trusecure.com/mailman/listinfo/hipsec