https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth
So since the WGLC came onto us a little early, the document authors still have some different opinions about some of this. So let me raise those in the WGLC :) INITIAL_CONTACT Section 2.3 tries to address the problem of not being able to trust INITIAL_CONTACT. Normally this payload is only honoured after authentication, but we don't have a real authentication here, and one anonymous IKE SA should not be allowed to obsolete another IKE SA. Valery suggests sending liveness checks to all IKE SA's that used AUTH_NONE. I suggested sending liveness checks only to those IKE SA's that used the same IP address, thus limiting the scope to a more likely pool of possible orphaned SA's by a remote that crashed/restarted. Of course, implementations can be smart, and skip liveness checks for those IKE SA's whose IPsec SA is showing traffic now in in the very recent past. We need to consider the harm of leaving orphaned SA's versus the harm of being tricked into sending too many liveness probes. And in general, we need to ensure one IKE SA isn't sending a zillion useless IKE messages - as we've lost the protection of a real authentication to punish abusers by locking them out. (if you thought ddos-puzzles were interesting, come tackle this problem :) Traffic Selectors We touched a bit on the traffic selector problem. If a peer is able to pick its own address, it could attempt to steal traffic (say 8.8.8.8) from the server. We advise people to isolate these peers. We cannot fully disallow this because we need NAT-traversal support. Valery preferred server assigned IP addresses (using CP) which will work great in the "sensor network" but would cause overlapping problems with IKE peers that talk to multiple peers that hand out their own range of addresses. And opens up the reverse attack of the server stealing the client's 8.8.8.8 traffic. Some more discussion and insights on this would be useful. Additionally, if we allow some kind of narrowed traffic selector, malicious IKE peers would only need their one IP and could setup (protocol * sport * dport) IPsec SAs. Or a variant of this could be done with when allowing CREATE_CHILD_SA to setup a plethora of IPsec SAs. Restrictions based on IP address is hard, again because of the NAT support problem. What we tried to do with the security consideration section is to keep advise generic. Then specific opportunistic IPsec related issues could find themselves in a soon to be draft-ipsec-opportunistic document. Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
