Re: [IPsec] CHILD_SA and PFS

Yoav Nir writes:
> PFS is different.  For other attributes, if the SPD entry says you  
> need, say, 3DES, and the other side's SPD entry says AES-128-GCM, then  
> you'll fail every time.  If you succeed, then your policies are matched.

Not really.

If your clients SPD says:

Local		Remote		Action
-----		------		------
192.168.2.1	10.0.0.0/8	PROTECT(ESP,AES)

and the servers SPD says:

Local		Remote		Action
-----		------		------
10.0.0.2	192.168.2.1	PROTECT(ESP,3DES)
10.0.0.0/8	192.168.2.1	PROTECT(ESP,AES)

Then if you happen to send first packet from client to 10.0.0.5
addres, the client will negotiate ESP IPsec SA with AES, and with
traffic selectors TSi = (192.168.2.1-192.168.2.1), TSr =
(10.0.0.0-10.0.0.1, 10.0.0.3-10.0.0.255), as the server will narrow it
down to that when proposed clients traffic selectors.

Now if the either end tries to negotiate SA between 192.168.2.1 and
10.0.0.2 that will fail. 

> With PFS is different.  One side can have an SPD entry saying PFS is a  
> must. The other SPD entry says PFS is must not. At any time except  
> during the initial exchange, this will fail, and rightly so - so the  
> users fix the problem.  But if it's in the initial exchange, it  
> suddenly succeeds. This practically guarantees usability problems for  
> any implementation.

PFS is no different there. It is just like any similar policy mismatch
error. In the case above the user thinks he has ok policy as he can
use most of the services from the office network, but for some reason
he cannot connect to the 10.0.0.2 server, even when everything else
works. 
-- 
kivinen@safenet-inc.com

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec