[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard
:> First issue can be partially resolved by having protocol
:> support logically equivalent to:
:> Host A negotiates a SA destined to Host B with Router R.
:
:Repulsive and dangerous to security.
Security of what: A, B or R?
:> Tricky logic, but can be technically achieved with modification
:> of current ISAKMP. While this might open a new sort of attacks
:> (I don't care), the router R can further differentiate IPsec traffic
:> by SPI value found in there.
:
:The "(I don't care)" worries me here.
Once the functionality is claimed to be in the spec, I would take care
about clearing corresponded security issues. Anyway, IMO,
preventing attacks on a security system splits on 10% of
good underlined specs and the rest 90% of how these specs were implemented.
:> Second issue can be resolved only under an assumption that host A and B
:> will reveal information to R that is equivalent to having the case:
:
:Sharing keys with intermediate routers is also a really, really,
:amazingly bad idea from a security standpoint.
I meant not 'sharing keys', but having nested SAs, terminating at different
end points.
:To recap, the two problems you are solving are:
:
:> 1. Fine grained Statistic counting
:
:Which doesn't strike me as so worthy a goal as to make security
:compromises necessary, and:
I don't have these problems for at least 6 months ;-), just
helping people on the list who asked about _their_ problems.
:> 2. Traffic Inspection on packet per packet basis
:
:Which also doesn't strike me as that important a goal in context.
Whenever people want port information to be revealed for filtering
purposes I'm just noting that ports information works for (1).
It _does_ not work for filtering purposes (2), because 'Port'
does not mean 'Service', right?
:
:Perry
I would vote to _not_ invent any new payloads for reasons explained
(may be not clear) herein.
--Alexei