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

Re: Mobile IPv6 - IPsec interaction.



Francis Dupont <Francis.Dupont@enst-bretagne.fr> writes:

>  In your previous mail you wrote:
> 
>    The exact contents and format of the SPD is implementation dependent.
>    There are some minimal requirements required by 2401.  But basically,
>    you would have something that says:
>    
>    	mobile-host 11.22.33.44 uses i-d fqdn.mobile.host with rsa-key XXX
>    
> => do you know an implementation which provides or will provide this
> (BTW I think the "with rsa-key XXX" is not needed, ie. this is done by
> the certificate and relies on the PKI config).

Well, that again depends on the implementation.  On Linux FreeS/WAN,
for example, the policy contains the RSA Key to be used (and the
identification is just a hint to make sure you use the right key).
Unfortunately there is no standard certificate exchange format for
IPSec (yet?).  But you are right, if you have a real certificate with
a real i-d binding, then yes, you don't need to include the key in the
policy, the identification is sufficient.

>    > => this (identification+authentication) is known to be not enough for
>    > the proper authorization.
>    
>    Why?
> 
> => because a policy must be involved. Phase I doesn't do the policy,
> it just estiblishes the context for the policy/authorization stuff.

Right, phase-I is the authentication.  The policy is checked and
enforced by phase-II.  And yes, that _IS_ done today, by selectors and
such.

> => we agree but some people want to see the corresponding running code
> (perhaps this is too much but this is a good thing for future
> interoperability so I agree that "add the authorization word in specs"
> is not enough for the real world).

I think any IPSec implementation that supports selectors "corresponds
to running code".  This does exist today.  It might not be integrated
with everything, but the code is there.  I've seen it working.

>    >    In the phase II my laptop will create tunnel between 11.22.33.44 and
>    >    the home agent, and now the home agent knows that this IKE SA
>    >    connection is bound to my laptop which then is bound to home address
>    >    of 11.22.33.44, thus this operation can succeed. 
>    >    
>    > => the "then is bound to" is our point: how is it done?
>    
>    Phase-II is _ALWAYS_ bound to phase-I, because the phase-II
>    negotiation is completed within the protection of a phase-I SA.  That
>    gives you the binding between phase-I and phase-II.  The two phases
>    are _NOT_ independent.  You cannot complete a phase-II without having
>    a completed (and valid) phase-I.
>    
> => but you justifies only the "this IKE SA connection is bound to my laptop",
> not the second binding.

Wrong.  Phase-I binds "this IKE SA is bound to my laptop."  Phase-II
leverages off that binding.  The home agent knows that "your laptop"
owns home address 11.22.33.44, so it will authorize the phase-II SA
for your home address based upon the authentication in phase-I.

This is just standard tunnel mode, and it exists today.  Remember that
the internal address of the tunnel need not be the same as the
external address of the tunnel.  Your policy defines what internal
addresses are allowed through a tunnel based on your endpoint
authentication from phase-I.

>    	1) Client identifies itself
>    	2) Client authenticates as identity
>    	3) Server verifies authentication and returns an error if it fails
>    	4) Client makes a request for a mobile-host binding <-- action
>    	5) Server looks up identity in policy database
>    		a) verifies that binding matches policy
>    		b) if not, return an error
>    		c) if binding matches policy db, perform the binding
>    
>    Steps 1, 2, and 3 are already done by IPSec.  Steps 4 and 5 are
>    somewhat IPSec and somewhat MobileIP.
>    
> => my concerns are steps 4 and 5: IPsec doesn't really explain how they
> are done and Mobile IP only requires them...

That's why we're writing standards -- they don't just magically appear!

But snide comments aside, you _can_ do this today: you set your policy
to build a tunnel that authorizes your mobile host (based on some
identification) to tunnel packets as your home address.  Seriously, it
is that simple.  I admit that _how_ you set your policy is IPSec
implementation specific.  However, _what_ you need to setup isn't.

For example, you want to configure your tunnel something like this:

On the mobile host:

	type=tunnel
	server=11.22.0.1
	server_id=server.my.site	<- used to authenticate home agent
	my_inside_addr=11.22.33.44
	my_auth_id=laptop.my.site	<- my authentication ID

On the home agent:

	type=tunnel
	client_id=laptop.my.site	<- used to authenticate mobile host
	client_inside_addr=11.22.33.44
	my_auth_id=server.my.site	<- my authentication ID

> Thanks

You're welcome.

> Francis.Dupont@enst-bretagne.fr

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available


Follow-Ups: References: