Some clarifications below.
(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.
I don't think that restricting liveness checks in this case to the same
IP address covers all the situations. The peer may crash,
reboot and get new IP from its ISP and then create new IKE SA.
In this situation (very common, not?) the proposed restriction
will prevent the server from finding that old stale SA and it will continue
to consume resources untill the server decides to send smth.
over it or to check its liveness based on a long period of its
inactivity or until its lifetime is over.
I don't think that the document should impose such a restriction,
but instead it should give some guidance of how implementation
should behave in this situation.
To clarify my position: I don't propose that implementation
should blindly send liveness check messages on
every SA once new one is created. If SA is active
(there was recent incoming traffic over it) or implementation
has just successfully finished liveness check on that
particular SA, then there is no need to do it again.
But if some unauthenticated SAs are idle for a while, then the event of
creating new unauthenticated IKE SA MAY (not SHOULD, not MUST)
trigger the liveness check on those SAs, regardless of their IP addresses.
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 :)
This is interesting problem, but I think that in general
implementations should be robust enough to deal with that.
Of course you may punish abusers if you know their
IDs, but it would be a shame on you if those abusers
could crash your implementation, just because their
implementations are buggy and send zillion messages.
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.
The server assigned IP addresses using CP is a standard
way of dealing with it. I admit that others are possible
and don't want to limit implementations to the only one.
And in general the problem of overlapping is irrelevant to NULL Auth.
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.
I think it is a server's policy issue. It can always restrict
the number of IPsec SAs from a single peer
by using NO_ADDITIONAL_SAS notification.
The document should not impose any restrictions here, IMHO.
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.
Exactly.
Paul
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
