command line ike and ipsec commands

Security Gateway Discussions
Post Reply
THaala
Posts: 29
Joined: 13 Jun 2008, 15:21

command line ike and ipsec commands

Post by THaala » 07 Sep 2021, 14:33

Hello,

i wonder why some ipsec SA can exist without covered ike negotiation.
I have a lot of "LAST RESORT" - VPN. Clients connect from mobile provider radio networks.
Because of all IPs are NATted very often this type of VPN works in IKEv1 with aggessive mode and NAT Traversal only.

However, because the of NATted IP-Addresses this cannot be used as Identity. Only FQDN or USER FQDN works as identity. It seems that clavister (W30 / V13.00.12) checks only the match of the shared secret. The identitiy seems always accepted but should not duplicate.

With "ike -show -num=all" i can see a lot of identity strings but not all. "ipsec -show -num=all" shows some ntworks which are correctly connected in same manner as others but the (well known) identity is not shown with matching ike command. ike command shows only a subset of it and only 16 signs of the identity - string.

i ask you now how this can happen. In my opinion an acive sa must be paired by an active ike cover - isnt'it?
Where are the missing identiity strings, or better the missing ike entries?

Params
Aggressive mode, USER FQDN Identity, encr AES256, SHA1, NATT enabled
IKE 28800 secs, DH group2, IPSEC 3600 secs / no Kilobytes PFS group 2.

BR
/Thilo

Peter
Posts: 697
Joined: 10 Apr 2008, 14:14
Location: Clavister HQ - Örnsköldsvik

Re: command line ike and ipsec commands

Post by Peter » Today, 07:45

Hello Thilo.
"In my opinion an acive sa must be paired by an active ike cover - isnt'it?"
Yes and no, this is actually allowed in IKEv1 but if you use IKEv2 this is forbidden. So in IKEv1 you could have an IKE timeout and the IPsec SA's still persists and everything is working fine. But when the IPsec also times out it requires an IKE to re-key, then it would create both an IKE and IPsec SA.

Since there is (normally) a higher IKE SA lifetime set than IPsec SA it will eventually lead to a situation where the IKE has expired and removed but not IPsec.

We recommend the use of IKEv2 whenever possible. Also you should try to move away from aggressive mode as soon as possible as it is susceptible to an amplification attack. This is what was written in the release notes for version 11.04.00 (long one):
COP-17194: Protocols using UDP may be vulnerable to being used in a DDoS attack to
amplify the effect of the attack. Implementations of IKE, both IKEv1 and IKEv2, have been
shown to be vulnerable (see http://www.kb.cert.org/vuls/id/419128 for more info). An
implementation following the IKEv2 specification (RFC 7296) isn't subject for the vulnerability
and cOS Core is following the RFC making it impossible to be used in an amplification attack
when using IKEv2 tunnels. cOS Core also follows the specification for IKEv1 (RFC 2408) which
makes it vulnerable to the attack. Changes have been made to cOS Core that will break RFC
compliance to mitigate the risk of being used in an amplification attack. cOS Core will no
longer resend responses to the first IKE message of a Main mode exchange. This is similar to
how the IKEv2 implementation works and will not cause issues with retransmissions.
Aggressive mode tunnels will still be vulnerable though, since changes to this exchange can't
be made to both protect against the attack and still have a functional retransmission process.
The recommendation is therefore to not use aggressive mode tunnels in a roaming scenario.
I.e. where LocalEndpoint attribute on the tunnel hasn't been set. Using aggressive mode in
this configuration would still make the Security Gateway subject for the attack.
Best regards
/Peter

Post Reply