[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Interactions between IPSEC and NAT
Alex,
>>Maybe you ought to read the spec. It might answer a lot of your
>>questions. Believe it or not, we did know what we were doing.
>
>I have to really question if you knew what you were doing. Go
>read Rogaway's cryptographic analysis--have you fixed the issues
>he raised? Are you still seriously considering a PK solution for
>managing trust? If so, then God help anybody that has to implement
>it and get a real customer to use it.
I don't think the current IPsec protocols suffer from any serious
cryptographic problems, but a more concrete pointer to the publication in
question is always appreciated. The use of PKC with IPsec is for
autehntication and key distribution. "Trust" is an overused term and it's
not clear that it applies here. This is especially true since IPsec allows
for various key management options and it certainly does not require
anything like a global key management hierarchy (if that's what you might
have been alluding to).
>>Your viewpoint is a wee bit unrealistic -- there is, in practice, no
>>way to make even a tiny fraction of the routers trusted. It is also
>>unneeded -- we know how to provide security in a network where nothing
>>except the endpoints need to be trusted.
>
>Unfortunately you have come up with a solution I find cumbersome,
>slow, difficult to administer, with an awkward trust model, no
>auditing, and no key recovery.
The level of admninistrative difficulty for IPsec will probably be
comparable to that of a stateless, pacvket filtering firewall, which is
just what one should expect for the prescribed level of access control
granularity. As I noted above, I don't think we have a "trust model" here,
so I cannot respond to that criticism. Auditing is a requirement for IPsec
implementations. Key recovery is not an explicit feature, but can be
provided through a variety of arrangements (if the market wants it).
Steve
References: