Yoav Nir writes: > > The reason why we defined IKEv2 so that initiator provides identity > > first, was that if responder provides identity first, then attackers > > can make probe attacks and collect identities of the remote peers, > > even when the IPsec is not currently in use. I.e., like we might run > > nmap to find out the open ports, this would also provide authenticated > > (if using certificateS) identity of the peer… > > I realize this, but one side has to identify itself first, and with > remote access I think it’s more important to protect the initiator > identity than to protect that fact that some organization has an > IPsec remote access concentrator.
IKE is not unidirectional, it is not only client and server, it is host to host. I.e., the remote access initiator should also respond to the incoming connections as it might be the restarted remote peer reconnecting etc. There might actually be real IP connection between (i.e., no NAT) which allows remote peer to connect to you too :-) > In fact we can run nmap and find which ports are open, and we can > and do scan for HTTP(S) servers on ports 80 and 443, and we do get > their certificates. For server yes, but my web browser does not listen port 80 or 443, and will not respond to them. My ipsec client will listen port 500 and 4500 and will respond to them. It might not allow incoming IKE_SA_INITs to them, or might not even implement them, but originally IPsec was seen more host to host than client to server... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
