Hi Dmitry
IKE protocol (IKEv1/IKEv2) is used to negotiate between 2 IPsec-Peer-Gateways to create IPSec-SAs on both gateways to enable encryption/decryption/integrity-checks of the data that is transferred between them in the ipsec tunnel that is established after the negotiation is over
IKEv1 protocol has 2 Phases called Main-Mode/Phase-1 and Quick-Mode/Phase-2
- In Main-Mode, there are 6 messages exchanged betwen the 2 peers that want to establish a ipsec tunnel
- Messag1&2 exchnged between the 2 peers contain algorithms-selected/etc (called proposals)
- Messages 3&4 are exchanged between the peers to pass to each some public values that are used in a formula/algorithm called Diffie-Hellman algorithm....here at this point both the peers would have create a symmetric encryption/authentication keys to start encrypting the next phase of exchanges between them..
- So now Messages 5&6 are exchanged between them and these are encrypted using the keys created in above step (after message3&4)
BUT in there is also a check that is for the Peers themselves to be mutually authenticated and to do so they have identifiers for themselves that are programmed/configured by you when you are configuring the s2s vpn tunnel and/or the C2S vpn server (and clients)
Only after this step (called the IKE-Authentication Exchanges of Main-Mode), and the auth is passed will the peers move to the next Phase-2/Quick-Mode (which is encrypted as messages-5/6 are).
So Identifiers that are used in the IKE-negotiation between the IPsec-Peers (used in IKE-Auth negotiation phase) are:
When PSK is used for IKE-Auth there are 3 standard IDs that can be used by each of the IPSec-Peers and both will exchange their IDs during IKE-Auth process
1. ID-Type-1: FQDN
- Here only in this case you may use values such as gw1.local.net, servergw.test.net, corpHQ.net, server.net, etc...but i suggest it should be in the form of "hostname.somedomain.net"...this proper, rfc-standard method...
2. ID-Type-UFQDN; User-FQDN
- this will be always in the email-id syntax: client@gate.net, client@branch.local.net, etc
3. ID-Type: IPAddress
- This will always be the default ID that is used when the user/admin does not explicitly confiure any other ID
- this will always be by default the wan-ipaddress/pubic-ipaddress using which the IPsec-Peers will communicate with each other...
- very rarely do admins confiure a ipaddress which is NOT the wan-ipaddress
When Certificates are used for IKE-Autth, there are 3 IDs that could be used
Note: It is at this point (after selecting Certificate for ike- auth) that the ID option ASN1DN becomes activated/displayed for selection in the RV-routers
1 ASN1DN: which will be the subject-field of the certificate used by that peer...its also called a Distinguished Name (DN)
2. FQDN : here it always would be the dns-address/fqdn that is present in the subjectAltName field of the certificate
3 UFQDN: here it will always be the email-id that is present in the subjecAltName field of the certficate used by the peer
In IKEv2 also, the method is similar/same (with some more advanced features also supported), but in IKEv2 the below are the phases/messages exchanged between the peers
a) IKE_SA_INIT messages 1 and 2
b) IKE-Auth messages 3 & 4 (and this where the Identifiers are exchanged)
c) CHILD_SA Messages (like quick-mode in IKEv1)
In all of these above, its to be noted for reference that the Local & Remote Identifiers are to be seen with each Peer's perspective
- for Peer1, local-id would be for itself, and remote-ID would be of Peer2
- and correspondingly and its in reverse, the remote-ID configured in Peer1 would be the Local-ID of Peer2, and the Local-ID of Peer1 would become the Remote-ID configured in Peer2
hope this info is useful for future reference and further study....check out the RFC for IKEv2(and IKEv1 for comparison)
