[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC, IPv6 and mobile IP
> I believe that "mobile-ipv6 and ipsec combination" is a headace.
> mobile-ipv6 document is very silent about:
As I'm in the process of planning an IPSEC integration with IPv6 stack
and mobility, I need to get my thoughts cleared on the issue.
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...].
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>
PROBLEM?
--------
Both seem to lead into solution where associations are between home
address(es).
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.
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].
> 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?
--
Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland
Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/
Follow-Ups:
References: