ipsec November 2007 archive
Main Archive Page > Month Archives  > ipsec archives
ipsec: Re: [IPsec] CHILD_SA and PFS

Re: [IPsec] CHILD_SA and PFS

From: Yoav Nir <ynir_at_nospam>
Date: Sun Nov 25 2007 - 09:14:26 GMT
To: Tero Kivinen <kivinen@iki.fi>


That's my point. The client can never connect to 10.0.0.2. It always fails, so the user tells the administrator that something is wrong, and (hopefully) it gets fixed.

With PFS, the connection succeeds and everything works. Then suddenly, it stops.

If I can get to the file server at 10.0.0.5 but not to the mail server at 10.0.0.2, I'm going to call the administrator. If the connection just stops after 30 minutes, I'm going to blame the ISP or the client vendor. I wouldn't associate a misconfiguration with this.

On Nov 22, 2007, at 4:44 PM, Tero Kivinen wrote:

> 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.

> 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.



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