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

From: [email-masked] (Henderson, Thomas R)
Date: Fri Jan 23 19:02:01 2004

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]] 
> Sent: Friday, January 23, 2004 11:27 AM
> To: Henderson, Thomas R; Julien Laganier; Marcelo Bagnulo
> Cc: <[email-masked]>
> Subject: Re: [Hipsec] Re: draft-nikander-hip-mm-01.txt
> 
> 
> Tom, Julien and Marcelo,
> 
> > I have some questions regarding the mobility draft.  Some
> > things have changed considerably since the time that REA was in
> > the base spec, and I don't understand the motivation for many of
> > 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.
> 
> > 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.
> 
> 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.
> 
> > Why does readdressing require return routability check (what
> > 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.
> 

Good point.  Maybe the replay protection window is temporarily inflated during periods of mobility?  

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

Understood now-- it is difficult to decouple NES from REA because of NAT.

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

Yes, that sounds like the most flexible approach.

> 
> > ii) There is an additional level of abstraction introduced called
> > an "interface."
> > (also, the overloading of the term "interface" may cause confusion
> > because most people have rather concrete conceptions of what an
> > interface is.)
> 
> 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
> > than one SA between any two hosts requires some way to index
> > 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.)
> 
> > But I question whether it is necessary, and if it is, shouldn't
> > 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.

Let me see if I can add some structure to what you are saying, modulated by what I was arguing for, and you can correct me where I am wrong.

                            address11     
                      SA1 <               
                     /      address12     
                    /                     
       association  - SA2                
     /                                     
    /                SA                  
host - association <                       
                     SA                     
 ...                                      

Hosts are defined by their unique host identities.  Sockets are bound to host identities and ports.  

Each host can have multiple HIP associations, which are stateful   signaling relationships between hosts.  Each host has only one HIP association active with any other given host at a given time.  The HIP associations exist to create and manipulate the SAs.  

Each HIP association can create one or more SAs used for data transfer for data emanating from sockets bound to the particular host identities.  The different SAs are indexed by their SPIs and directionality (inbound/outbound).    

Each SA is affiliated with a subset of local addresses on the host machine.  By default (without REA), a single outbound SA is set up to the peer host, with a single destination address affiliated with the outbound SA.   A single inbound SA is set up as well, and the peer host knows of one address to send data to on that inbound SA as well.   

A given IP address may be affiliated with more than one SA.  Likewise, a given SA can be affiliated with more than one source and destination address.  Multiple SAs can exist for an association, governed by similar policy.  For outbound packets, the kernel selects the appropriate outbound SA, and also the appropriate source and destination addresses, based on the host identities that are bound to the socket and the current multi-homing situation.  (Note:  how to select is an open issue).  Inbound packets are accepted on any inbound SA, provided that they decrypt and pass replay window protection, and the IP addresses are not used as selectors for the SA.  Inbound packets are demultiplexed based on the host identities bound to the incoming SPI, and the transport ports.

REA is the mechanism for adding an address to or deleting an address from a SA.  More generally, REA is used with NES to set up new SAs with new SPIs.  To possibly traverse NATs at a new location, upon relocation, both hosts should send NES so that they expose their SPIs to the NAT.  It is the policy of the mobile or multihomed host to decide when to send REA or NES.  There are unresolved issues with respect to transport layer signaling or hooks to handle the fact that transport connections may be changing paths over time.

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

I think so too, but we would need to come up with a compelling mechanism that would convince e.g. SCTP that their mechanism is redundant.  

> 
> > Should more work on the SLAP concept be done?
> 
> Definitely, IMHO.  But maybe slightly later.
> 
> > 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.
> 
> 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.
> 
> > This also gets into the question of whether it is HIP's job
> > to determine which of possible addresses should be primary.
> 
> Indeed.
> 
> > 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.
> 
> 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.)

Sorry, I must have missed the multi6-hip-00 document.  Or maybe it is not published yet.

Tom

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

---

From: [email-masked] (Pekka Nikander)
Date: Sun Jan 25 19:26:00 2004

Tom, (Jari, see a note about MOKIKE close to the top.)

[Writing off-line, not seeing possible replies in between.]

> inflated during periods of mobility?

Maybe.  This is probably something that we want to consider
at the MOBIKE WG.  They have the same problem.
Jari, do you have an opinion on this?

> Understood now-- it is difficult to decouple NES from REA

It can sure be expressed in that way.  I would say that
because of NAT, it is always necessary to explicitly carry
the SPIs in REAs, leading to considerable overlap in NES
and REA syntax.  Secondly, for multi-homing with paths with
different QoS characteristics, it is often necessary to
introduce new SAs in REAs announcing new addresses.
 =46rom there on, it is a small step to integrate them also
functionally and semantically.

However, I am still not sure whether this is the right
thing.  I thought so before writing -01, but I am not *so*
sure any more.  I guess I need some implementation insight.

> Yes, that sounds like the most flexible approach.

Ok.  I'll try to add that.

> Let me see if I can add some structure to what you are
> saying, modulated by what I was arguing for, and you can
> correct me where I am wrong.

Ok.  In general, your text looks excellent.  Maybe we should
add it to the introduction in -mm-02?

>
>                             address11
>                       SA1 <
>                      /      address12
>                     /
>        association  - SA2
>      /
>     /                SA
> host - association <
>                      SA
>  ...
>
> Hosts are defined by their unique host identities.
> Sockets are bound to host identities and ports.

Ok.

> Each host can have multiple HIP associations, which are
> stateful signaling relationships between hosts.  Each
> host has only one HIP association active with any other
> given host at a given time.

Ok.

> The HIP associations exist to create and manipulate the SAs.

Well, this depends on your point of view.  If you take a
different angle, you could say that HIP associations exist
to allow transport layer sessions to survive changes of
underlying IP addresses.

> Each HIP association can create one or more SAs used
> for data transfer for data emanating from sockets bound
> to the particular host identities.  The different SAs
> are indexed by their SPIs and directionality
> (inbound/outbound).

Ok.  [Well, to be precise, each HIP association seems to
require at least two SAs (instead of just one).]

> Each SA is affiliated with a subset of local addresses
> on the host machine.  By default (without REA), a single
> outbound SA is set up to the peer host, with a single
> destination address affiliated with the outbound SA.
> A single inbound SA is set up as well, and the peer host
> knows of one address to send data to on that inbound SA
> as well.

Right.

> A given IP address may be affiliated with more than one SA.
> Likewise, a given SA can be affiliated with more than one
> source and destination address.  Multiple SAs can exist for
> an [HIP]=A0association, [all] governed by similar policy.

Yes.

> For outbound packets, the kernel selects the appropriate
> outbound SA, and also the appropriate source and destination
> addresses, based on the host identities that are bound to
> the socket and the current multi-homing situation.

Agreed.

> (Note:  how to select is an open issue).

Right.  Right now we are looking at simple heuristics
based on data coming from the PF_ROUTE socket.

> Inbound packets are accepted on any inbound SA, provided
> that they decrypt and pass replay window protection, and
> the IP addresses are not used as selectors for the SA.
> Inbound packets are demultiplexed based on the host
> identities bound to the incoming SPI, and the transport
> ports.

Right.

> REA is the mechanism for adding an address to or deleting
> an address from a SA.  More generally, REA [can be] used
> with NES to set up new SAs with new SPIs.  To possibly
> traverse NATs at a new location, upon relocation, both hosts
> should send NES so that they expose their SPIs to the NAT.

Yes.

> It is the policy of the mobile or multi-homed host to decide
> when to send REA or NES.

Yes.

> There are unresolved issues with respect to transport layer
> signaling or hooks to handle the fact that transport
> connections may be changing paths over time.

That's right.  And a very interesting area to study, in my
opinion.

> I think so too, but we would need to come up with a compelling
> mechanism that would convince e.g. SCTP that their mechanism is
> redundant.

Patience :-).  I discussed with Randall Stewart and Michael
T=FCxen.  Sure they were skeptical, but they were also very
interested.  And I learned a lot.

> Sorry, I must have missed the multi6-hip-00 document.  Or maybe

I sent it to the drafts editor a few days ago.  I don't know
when it will be public.  Once it is, I will announce it also
at hipsec list.

--Pekka