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

[Tero Kivinen <[e-mail]>]

Valery Smyslov writes:
> > 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.

Or the implementation could just do n liveness checks for
unauthenticated clients per second. I.e. go through all your
unauthentication clients ever now and while, and see whether you need
to clear the resources. How fast you want to go through them depends
how much resources you have left. If you have plenty of resources,
there is no need to wast other resources to clean up some other
resources. If you are running out of memory because you have too many
unauthenticated IKE SAs then send liveness check to them faster (==
consume more CPU resource), to clean up resource you are running out
(==memory).

This all is implementation details. We could give some hints here, but
I do not think we want to make any hard rules...

> > Traffic Selectors
...
> > 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.

Actually I think I am missing something. How can server steal clients
8.8.8.8 traffic? Even if it assigns client 8.8.8.7 IP address, that
does not mean 8.8.8.8 is sent to the server. Server can assign 8.8.8.8
for the client, which means that 8.8.8.8 traffic from the client does
not go anywhere (i.e. it is routed to localhost, because client think
it is his own IP), but that does not allow stealing traffic.

Assigning address using configuration payloads do not affect routing
table. Only traffic selectors and perhaps INTERNAL_IP*_SUBNET stuff
might affect routing, and client should not ever allow traffic
selectors which are wider than what his policy allows. For
unauthenticated host-to-host conection client would always put exactly
one IP address (servers IP-address) to the TSr when proposing traffic
selectors, and server cannot make it wider than that.

Also client can easily limit that address assigned to it via
configuration payload must be from the private address range, as there
is no reason for server to assign client real routable IP-address in
unauthenticated user case. But again this is policy decision which
implementations need to do.

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

Agree. Implementations might also have different limits depending
whether the other end is authenticated or unauthenticated, i.e.
unauthenticated clients might only be able to create for example 10
Child SAs, and authenticated clients can create 1000 Child SAs... And
btw child SAs are quite cheap, so the limit does not need to be 1 and
3... :)

On the other hand on some environments Child SAs are expensive, for
example if you have hardware acceleration which  only supports limited
amount of SAs. In those environments the server's policy might
disallow per flow SA.
-- 
[e-mail]