What does it mean that Ikev1 (IPSec) protects peer identities in main mode?

Question

Does it mean that the source IP is replaced with something else (like if in IP spoofing) so intermediate routers don't know who is sending the packet?

Answer 1

Identity here does not have anything to do with peer IP addresses, which indeed are both visible for anyone along the route. Instead, the identity refers to public keys, as they would identify the peers. From IKEv1 (obsoleted by IKEv2, RFC 7296) Phase 1 Authenticated With Public Key Encryption, RFC 2409, 5.2:

In order to perform the public key encryption, the initiator must already have the responder's public key. In the case where the responder has multiple public keys, a hash of the certificate the initiator is using to encrypt the ancillary information is passed as part of the third message. In this way the responder can determine which corresponding private key to use to decrypt the encrypted payloads and identity protection is retained.

In addition to the nonce, the identities of the parties (IDii and IDir) are also encrypted with the other party's public key.

The identity protection means that anyone eavesdropping the connection cannot tell anything about the public keys of the peers. Therefore, they only have the IP addresses, but not the identities.

Answer 2

Note that authentication with public key encryption, as suggested in the other answer, is very rarely used for IKEv1 (it's not an option anymore for IKEv2).

Instead, authentication with signatures (RFC 2409, section 5.1) is a lot more common, or using pre-shared keys (RFC 2409, section 5.4).

For all of them, the "identity protection" aspect derives from the fact that messages, starting from the fifth in IKEv1 main mode, are encrypted using a key derived from an ephemeral Diffie-Hellman exchange. So the identities (IDii, IDir payloads) and certificates exchanged in those messages are protected from a passive attacker.

You can see that in the diagrams in the RFC (HDR* indicates payload encryption), e.g. for signature authentication in IKEv1 main mode:

    Initiator                          Responder
   -----------                        -----------
    HDR, SA                     -->
                                <--    HDR, SA
    HDR, KE, Ni                 -->
                                <--    HDR, KE, Nr
    HDR*, IDii, [ CERT, ] SIG_I -->
                                <--    HDR*, IDir, [ CERT, ] SIG_R

Only the SA payloads (algorithm negotiation), DH public values (KE payloads) and nonces (Ni/r payloads) are exchanged unencrypted.

This is generally not the case for aggressive mode (unless authentication with public key encryption is actually used), where the identities and certificates are not protected (although the third message can optionally be sent encrypted, which would protect the client certificate):

    Initiator                          Responder
   -----------                        -----------
    HDR, SA, KE, Ni, IDii       -->
                                <--    HDR, SA, KE, Nr, IDir,
                                            [ CERT, ] SIG_R
    HDR, [ CERT, ] SIG_I        -->

For IKEv2 (RFC 7296), all messages after the final IKE_SA_INIT response (due to COOKIE or INVALID_KE_PAYLOAD notifies, the IKE_SA_INIT exchange could be repeated) are encrypted. Identities and certificates (exchanged in IKE_AUTH messages) are therefore protected from passive attackers.