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

["Valery Smyslov" <[e-mail]>]

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.