On Tue, 9 Sep 2014, Les Leposo wrote:
Sure, CPU and RAM are not as expensive as "fast-path" or SA "tables" typical
found in servers with hardware acceleration - prior to this proposal,
these expensive resources were (typically) reserved only after authentication
(and child SA nego succeeded).
No one is telling you to enable this by default.
However, with this proposal, the server will be allocating these resources
anyhow because it can't judge between a good vs. bad client.
In the same way as you cannot judge between different half-open IKE
connections. Nothing really changes, and a few (tens of thousands) of
lines in the SADB shouldn't be that hard on a kernel. Clearly you won't
enable this on your embedded $20 router.
And the server could always limit the number of unauthenticated
connections
absolutely, it would help the server implementors, if this proposal required
such safe guards- others would be rate-limiting and perhaps shorter
Child-SA lifetimes.
Resource management depends on local resources. Therefor these are
typically left for local policy to decide. Is there any reason to
do that differently here?
2) this feature could also tempt network admins to fallback to
'null authentication' as a work-around/short-cut in cases
where they are unable to properly configure a deployment.
The Security Considerations must strongly discourage to do it.
Concur.
Do our security considerations state not to use "secret" as a PSK? Sure,
we should give some sane security advise, but we shouldn't talk about
obviously stupid things to do like purposefully degrading your security.
Concur, the sensor data would have to be inconsequential.
Because even when the measurement is not secret, a rogue "sensor" could easily
pollute the central data which could be bad especially if the data
is consequently used to control e.g. the cooling plant.
That still assumes neither party authenticates. There is a big
difference between one-sided authentication (like most ssh and tls)
and no authentication (like most port 80)
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
