Hi Matt. Because identities are not known until the IKE_AUTH exchange, it is always necessary to do a preliminary PAD lookup (see RFC 4301 for the Peer Authorization Database) based on IP address (and possibly local identity, depending on whether you configure that outside the PAD or discover that from the PAD) and to either verify the PAD entry once the identities are known or else do a subsequent PAD lookup using the final identities. You might have even noticed in the IKE_AUTH exchange, that if the initiator sends the optional IDr payload, the responder is not obligated to use that IDr as its own identity. So even if the initiator has hinted it prefers a certain IDr, it should do a second PAD lookup once it receives the IKE_AUTH response to verify that the negotiated SA conforms to its policy based on the actual IDr.
So a compliant implementation will do an initial lookup by IP address just as you describe, followed by a later lookup or verification using the identities. Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Matthew Cini Sarreo <mci...@gmail.com> To: ipsec@ietf.org Date: 04/08/2009 04:16 AM Subject: [IPsec] IKEv2: Possibility of "storing" configuration (Cryptographic Suite) for a certain Peer Hi everyone, As to my understanding, in IKEv2 it is not possible to know "who" the peer is until IKE_AUTH, by using the ID payload for that peer. Let us say that an implementation chooses not to use any automatic configuration but decide (by manual configuration) to accept only a certain Cryptographic Suite. As an example, let us say that after a peer (initiator) sends a message to another peer (responder) requesting a new IKE2 SA (IKE_SA_INIT), the responder would reply with INVALID_KE_PAYLOAD. The configuration as above would not send a new IKE_SA_INIT message with a corrected D-H group but halt the negotiation. In such a scenario, it might be required to have different D-H groups for different peers. Due to the ID payload being inexistant at this time, is there a way (that is allowed) to identify a peer during IKE_SA_INIT (for example, based on an IP address that has been stored in a configuration file that is known to always be for a certain peer), or are such identification methods (IP-based during IKE_SA_INIT just by checking the IP address source in the IP header of an IKE_SA_INIT message) prohibited? P.S this point comes from the IKEv2 RFC, section 2.6 (IKE SA SPIs and Cookies), par. 2 which states: "Incoming IKE packets are mapped to an IKE SA only using the packet's SPI, not using (for example) the source IP address of the packet." But the "identification" for fixed configuration purposes would be before this, as the packet would not be mapped to an SA, but a configuration for the SA resulting my that message would be loaded from configuration. Regards, Matt_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
