On Tue, 13 Jan 2015, Graham Bartlett (grbartle) wrote:
Hi Valery / Paul
[ CC:ing this back to the list ]
Or maybe you have 1000 sensors and there is only 250 IP addresses in the
DHCP pool, as you say the sensor is meant to wake, then send, then
sleep.
But it wakes, sends and keeps the IKE SA open, which prevents other
sensors connecting.
Please, see above. I assumed it should delete IKE SA before going into
sleep.
It should delete the SA (in a perfect world), but what if it didn't sleep
and stayed awake forever.. As peers can't be authenticated then it allows
an easy self inflicted DOS. :-)
Well, anonymous IPsec is a self inflicted DOS :)
If it remains awake then normal liveness checks combined with IKE/IPsec SA
lifetimes should handle the cleanup.
What I was alluding to is covered now in section 3.2 (and in Paul's
email). However I think some final words at the end of 3.2 such as 'For
this reason systems should be designed to accommodate legitimate and
non-legitimate non-authenticated peers', would then make this message
crystal clear.
Can you propose text? I personally find "legitimate and non-legitimate
non-authenticated peers" very unclear. I don't think a server can ever
tell those two aparts based on IKE.
The following are just minor syntax errors which I noticed;
'The KEv2 Authentication Method value for the NULL Authentication' -
missing 'I' ?
'Un-authenticated IKE sessions MUST only attempted when authenticated' -
'MUST only be attempted' ?
Thanks, we will fix those in the next version.
I have seen Paul's email from this afternoon which covers everything I was
trying to say (and more!). My personal feeling is that a new session being
authenticated should not initiate a liveness check on ALL connected peers.
I feel that the liveness check should be performed on an idle time (or
Pauls idea of only checking the same IP address), otherwise an attacker
would know when they connect then the headend sends a liveness check to
all connected peers, if you had a headend serving many 1000s of peers this
is an easy amplification attack.
And as Valery said, if your IKE SA shows activity (or perhaps even if
the IPsec SA shows activity on the inbound SA) why not skip the liveness
check for those peers, even if those are using the same IP.
I found it interesting that Valery and I think quite differently about
liveness. I always think of it as something to do on idle peers to see
if they didn't vanish. Valery thinks there is no point sending a
liveness check on an idle peer if you don't have any traffic anyway.
It all comes down to which resources you are protecting. If you have
enough memory, Valery's approach is valid, don't bother with sending
liveness packets because the IKE SA and IPsec SA are just a few bytes
of lingering data. Not worth sending (encrypted) network traffic for.
But if the host is getting too many IKE/IPsec SAs, those might be
worth poking to clean up.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
