|Main Archive Page > Month Archives > ipsec archives|
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.
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. -- firstname.lastname@example.org _______________________________________________ IPsec mailing list IPsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec