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

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

replying both to Marcelo and Julian, who had similar responses
(marcelo's comments inline)

> >
> > Why does readdressing require return routability check (what is the=20
> > attack?)
>=20
> As far as i understand, this is very important in order to=20
> prevent flooding attacks.

OK, I see this now, but there are scenarios for which the two hosts
trust each other (e.g., non-anonymous mode) so it would be preferable=20
in my view to make RR an option for the host receiving a REA.  I=20
would like to keep a lightweight readdress option--=20
so could we have two possible modes?

REA ->
<- REA-ACK=20

REA ->
<- REA-ACK (cookie)
REA-CONF (cookie) -> =20

NES is an option for either of the above exchanges.  This puts
control in the responder's hands as to whether the REA initiator
is trusted enough to readdress without cookie challenge, and it
leaves control in the REA initiator's hands as to whether it
wants to rekey the SA.

> > ii) There is an additional level of abstraction introduced=20
> called an=20
> > "interface." =20
> >
>=20
> I really don't have an opinion about the term interface, but=20
> i think that a introcuding a way to group multiple addresses=20
> and not all of them as in a node it would be useful. I think=20
> there are possible scenarios where you want that a certain=20
> communication can use a set of addresses but not all the=20
> addresses available in the host. This may be because using=20
> different addresses may have different properties.
>=20
> For instance, if you consider a multihomed site, that obtains=20
> addresses from each of its providers, and you also assume=20
> that some ingress filtering is in place, using a certain=20
> address implies selecting a certain provider. So you have 3=20
> addresses and 3 providers. Perhaps you want to use only two=20
> 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=20
> with the interface concept and only allow such communications=20
> to use a certain interface that groups only those selected=20
> addresses. But perhaps i am misunderstanding something here....

I am not so much questioning whether it may be useful to have
multiple SAs (with possibly different address bindings) between=20
hosts; rather,=20
i) whether the interface construct is explicitly needed,=20
as opposed to just using the SPI instead
ii) should the concept be introduced here rather than in the base=20
spec or architecture.  e.g., what is the Interface ID of the SA set=20
up during base exchange?
(I previously had some questions about how to handle multiple SAs
between hosts and how it might impact the base exchange-- e.g.=20
Note 3 in the below message):
http://honor.trusecure.com/pipermail/hipsec/2003-September/000029.html

If we just say that we can have multiple SAs tied to a HIP
association, each SA indexed by SPI and with perhaps distinct
address sets, what do we lose from not having the interface concept? =20

Is the logical concept of interfaces more of an implementation
issue? (that is, an internal housekeeping issue?)  I'm not seeing
why I couldn't get similar policy granularity with existing
mechanisms.

>=20
> > iii) as for multihoming, the architecture is unclear.  How=20
> does this=20
> > play with SCTP dynamic address reconfiguration, which looks=20
> similar to=20
> > me (allows multiple addresses to be in use, for purposes of=20
> recovery=20
> > via alternate path-- and in the future, load balancing?--=20
> and allows=20
> > one address to be "primary").
> >
> > Are both needed?  Should HIP mechanism replace transport level=20
> > multi-address handling?  Should more work on the SLAP=20
> concept be done? =20
> > Note also that if congestion control continues to live in the=20
> > transport protocol above HIP, it is not appropriate to hide the=20
> > presence of multiple possible source and destination addresses=20
> > (multiple paths) from transport, so it is probably not=20
> appropriate to=20
> > infer that transport level connections need not have any notion
> > of underlying IP addresses anymore with HIP.
>=20
> Very good questions.
>=20
> My view is that those different mechanism complement each other.
>=20
> LEt me ask you a question from a different perspective, what=20
> happens with regular TCP communications, or with UDP communications?
>=20
well, of course, TCP cannot presently multihome.  If you read the
dynamic SCTP addressing draft, it looks a lot like HIP readdressing
might.  However, SCTP as presently specified only does retransmission
across alternate paths.  The general host multihoming problem has=20
not been thoroughly handled yet IMO.

> Enabling multihoming and mobility mechanisms at the HIP layer=20
> enables these single address tranpsort layer to benefit from=20
> multiaddresssing.
>=20
> So fully agree with you, if the transport layer is aware of=20
> the multiple addresses and knows how to handle them, so let him do it.
>=20
> But if the transport layer don't know how to deal with this,=20
> handling multiple addresses at the HIP layer IMHO clearly=20
> provides a benefit.
>=20
> agree?
>=20
Yes, but I am thinking that maybe some kind of address change
trigger might be needed to the transport layer to indicate that
there may have been a path change.

I think that HIP should handle multihoming-- I just don't think
it is clear yet how it will do so and how it will interact
with transport.  And some of these questions touch on=20
mechanisms outside the scope of HIP.  For example, there is no=20
RFC guidance on what to do with congestion control state if a=20
host changes its source address used on an active transport=20
data flow.

> >
> > This also gets into the question of whether it is HIP's job to=20
> > determine which of possible addresses should be primary.
> >
> > Maybe the approach, suggested by Marcelo in a previous=20
> post, towards=20
> > specifying only a basic mechanism for mobility (change primary=20
> > destination address to use for IPsec transport layer outer=20
> header) is=20
> > the prudent approach for now, with more comprehensive=20
> multihoming (and=20
> > perhaps mobility
> > extensions) coming later.
> >
>=20
> I think tha defining extensions to add and remove addresses=20
> are important for multiple problems, such as mobility and=20
> multihoming. Those extensions are common to all these=20
> problems, so that what i think that they should be defined in=20
> a separate doc independeltlly of multihoming or mobility.=20
> This is also becasue only this extension don't really address=20
> these problems completelly, they are just a part of the solution.

That was my impression after reading mm-01.  Maybe we can fix
these things or maybe we need additional drafts. =20

Tom

---

From: [email-masked] (marcelo bagnulo)
Date: Fri Jan 23 10:22:00 2004

> trust each other (e.g., non-anonymous mode) so it would be preferable
> in my view to make RR an option for the host receiving a REA.  I
> would like to keep a lightweight readdress option--
> <- REA-ACK
> REA-CONF (cookie) ->

Well, the point here is who is the victim, i guess.

You have A and B that trust each other, so you suggest that they could just
skip the RR procedure for additional addresses.

So A asks B to start sending its traffic to address C.

Now, neither A nor B is damaged here but C is the one who is attacked

I mean, if A trusts B it can take some risks that concern him and himself
only.

However, not performing RR endanger other parts like C so it is not up to A
to decide this, IMHO it is up to the protocol designer to make sure that
this doesn't happen

But my criteria may be wrong here....

[...]

> there may have been a path change.

yes!

> with transport.

Yes

> And some of these questions touch on mechanisms outside the scope of HIP.

Yes

Agree with you completelly.
as you see,we have lots of work to do

But imho an incremental approach is good.

We clearly need a mechanism to add more addresses, so we need this draft.
Then we will need more stuff indeed

Regards, marcelo

>  For example, there is no
> RFC guidance on what to do with congestion control state if a
> host changes its source address used on an active transport
> data flow.
>
> > >
> > > This also gets into the question of whether it is HIP's job to
> > > 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
> > 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 things or maybe we need additional drafts.
>
> Tom
>
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec