[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 64-bit identifiers
In your previous mail you wrote:
On 2001-08-15 17:17:38 +0200, Francis Dupont wrote:
>
> => low overhead (i.e. BAKE, SUCV) proposals won't apply (no home
> agent), higher overhead (i.e. IKE, HIP) proposals provide the required
> security level but rely on a global PKI... I really don't know what is
> the worst: to accept MITM attacks or to wait for DNSSEC?
MITM seems like a problem that multi6 doesn't have to solve.
=> yes and no, look at below.
If a "gang-of-IP's" protocol is used, as long as it doesn't preclude host
authentication for users/admins/hosts/protocols that care about it, then
solving the problems of redundacy and load sharing seem like the thing
to worry about.
=> this is the point and this is not so easy. Today IPsec (i.e.
security in the network layer) and any "gang-of-IP's" protocol
(as we can see with address based mobility protocols like MIPv6)
are fighting together with very bad consequences:
- a lot of crypto stuff already done for IPsec will be redone
(a real concern if we'd like to get correct crypto)
- people will make bad assumptions about security level
- IPsec will remain "orthogonal" and it use expensive
Summary: people won't pay the extra cost for IPsec when a high security
level will be needed. What we need is integration of some IPsec
basic mechanisms into the "gang-of-IP's" protocol in order to provide
reliable security with for a minimal extra cost (i.e. in the key management
only) the optional & high security level given by IPsec.
I think most businesses today would be happy with an anonymous
end-to-end connection
=> this will be the job of "opportunistic" modes.
since they rely on web certs for their only authentication in the
current Internet. I'm not saying this is a good
thing, but again, not one that multi6 needs to address.
=> I'd like to get both some flexibility for multi6/mipv6/... and
security levels required by policies. I don't want to get only one
or to do things (like tunneling) twice. It seemed there were many
conflicts between multihoming/mobility and security areas but HIP
has shown the things are changing!
Regards
Francis.Dupont@enst-bretagne.fr