Re: [IPsec] WG Last Call on "The NULL Authentication Method in IKEv2 Protocol" draft-smyslov-ipsecme-ikev2-null-auth (fwd)

[Paul Wouters <[e-mail]>]

(seems previous message was lost)

>> 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