[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPSEC, IPv6 and mobile IP

> CASE A: Receiving packet from mobile (Home Address option)
> ----------------------------------------------------------
> What is the correct processing of a received packet that includes home
> address option and IPSEC. The packet arrives from a mobile host HA to
> non-mobile (to keep example simple) host B.
>
> Before destination option processing (Home Address) it looks
>
>   (1) IP(CA->B),DOP(HA),<some-ipsec SPI>....
>
> and after processing it will look
>
>   (2) IP(HA->B),DOP(HA),<some-ipsec SPI>...
>
> The simple question is: which of the following alternatives are taken
> by other implementors?
>
> a) Process IPSEC at point (1), e.g. look for matchins SA based on
>    triplet <AH/ESP,SPI,B> and check header against IP(CA->X),
>
> b) Process IPSEC at point (2), e.g. look for matching SA based on
>    triplet <AH/ESP,SPI,B> and check header against IP(HA->X),
>
> c) Try both (a) and (b), and drop packet if neither passes
>
> Because I don't like "trial and error solutions", I would prefer
> either (a) or (b), and to preserve at least some of the IPv6
> sequenctial processing of extension headers, one could perhaps give
> the preference to (b)? [disregarding at the moment the potential
> complexities in actually generating this packet in the source end...].
>

The MSRIPv6 stack does (b).


>
> CASE B: Receiving packet on the mobile host (routing header)
> ------------------------------------------------------------
> The next issue is when the mobile host HA receives a routed packet
> from B (B uses routing header to direct the packet to HA):
>
> Before processing the routing header
>
>   (1) IP(B->CA),RTH(HA),<some-ipsec SPI>....
>
> and after processing the Routing header (RTH)
>
>   (2) IP(B->HA),RTH(CA),<some-ipsec SPI>....
>
> Here the situation is simple, because (2) is the only possible choice
> [IPSEC specifies that routing header should be in the "final
> state"]. Thus, one should look for <AH/ESP,SPI,HA>
>

Number 2 in this case for the reason you state.

>
> PROBLEM?
> --------
> Both seem to lead into solution where associations are between home
> address(es).
>

I feel the association should be between the home address since mobility is
suppose to be transparent.  However when a mobile node visits another
network and gets a care-of address, additional IPSec may be required.  Note
I say additional and not alternative.  The IPSec with the home address is
still done.  The mobile network may have a security gateway protecting the
network.  I don't think you'd see IPSec done to the actual care-of address
because that means the mobile node needs to reconfigure the security
policies when it goes mobile.  I look at it this way from the correspondent
node's view point:

Sending:
    1. Do IPSec for traffic destined to the home address
    2. Discover the care-of address
    3. Do IPSec for traffic destined to the care-of address (most likely a
security gateway)

Receiving:
    1. Do IPSec for traffic from the care-of address (security gateway)
    2. Discover home address
    3. Do IPSec for traffic from the home address
    4. Validate IPSec

Two problems exist in this example:
    1. What happens if there was an SA bundle for the home network
    2. Validating the IPSec on the correspondent node to account for the
care-of address

Both are discussed in "(IPng 7578) mobile-ipv6 and ipsec" 6/2/99, on ipngwg
list.

> What is the arrangement of extension headers that would allow IPSEC
> associations between the care address(es) (a connection to the issues
> addressed by some posts from Richard Draves, concerning a mobile host
> moving into area where care address needs to use security gateways).
>
> Especially case B is "nasty". There is no way you can run IPSEC
> "legally" at stage (1), but even with case A it would require the
> "trial and error approach": to try both (1) and remove "layer of ipsec
> headers", if it succeeds.
>

If there is additional IPSec to the actual care-of address, the problem is
the security policies.  IPSec can be done but should be tunnel mode to the
care-of address.  The headers must be processed sequentially so tunnel mode
is required to do IPSec before the routing header.  An earlier discussion on
ipngwg list "(IPng 7193) RE: Last Call: Mobility Support in IPv6 to Proposed
Standard" 2/18/99, looked at why tunnel mode is needed for routing headers.

Again, I think you would see the IPSec for the care-of address to a security
gateway and not the actual node.   But if it is to the actual node, then the
validation needs to know about the care-of address like my correspondent
node example.

Basically when mobility is involved, two IPSec lookups are done on the send
side (first for the home address second for the care-of address) and the
IPSec validation on the receive side needs to account for the care-of
address.

> Binding Update issues
> ---------------------
> Mobile wants IPSEC to protect the binding updates. As these are
> destination options, it almost appears if I need to allow destionation
> options as selectors, so that the IPSEC policy could be properly
> specified for those too. [without making mobile IP an ugly special
> cast wart on the IPSEC].
>

I would just do AH or ESP for all traffic from the mobile node to the
correspondent node.  Yes if you just wanted the binding updates to undergo
IPSec, you would need some selector to indicate this.

> > There was some discussion on ipngwg mailing list recently, but
> > there seem to be no consensus about it.  There'll be mobile-ipv6
> > connectivity test workshop in September so we'll see...
>
> Hmm.. I suppose the announcement has gone at time when I was not yet
> too keenly aware of my need of mobile IP integration. Where and when?
>

About three weeks ago:
    "mobile-ipv6 and ipsec" thread starting on 6/2/99 on ipngwg list.

I hope this helps.

Aaron
References: