[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Death to AH (was Re: SA identification)
In your previous mail you wrote:
So, as somebody who thinks that:
a) the IESG's concerns about using IPsec to
correspondent nodes to protect BU's are
well founded
=> I think the only strong argument is the authentication of random CNs
and this is not really a technical argument...
b) that AH should be nuked in general to
simplify IPsec
=> the issue is to nuke enough but not too much (:-)
c) using IPsec between the mobile node and
it's home agent for binding updates as
well as *some* well known CN's (ie, not
for the random web browsing case) is a
good thing, especially if it provides
better security properties than the
ultimate solution for (a)
=> c) is possible and even easy for home registration (ie. MN-HA
interaction) which is a case where we *want* as good as possible
security. I believe an option will be necessary to go from a) (default)
to c) but c) will be IPsec like, not real IPsec.
I'd say that we either need to come up with
an application layer security schemes for
BU's which address (a) and (c) simultaneously
or have a means to have base level IPsec
protect BU's which are not dependent on AH.
=> clearly IKE as it cannot (should not) be used so this will be
an IPsec like.
Charlie brought up -- and I think I agree --
that it would be unfortunate if two nodes
that were already running IPsec between
them and they didn't raise the "global PKI"
spectre couldn't use IPsec to authenticate
and authorize the BU.
=> I have a different concern: it will be very bad to have IPsec
and mobile IPv6 new built-in security fighting together.
In general I think IPsec must be far more mobility aware....
A trivial case is a
mobile SIP phone with an SA between it and its
first hop proxy which have the same localized
PKI properties as the SA between the HA and MN.
(indeed, between HA and MN, there may be no need
for a PKI at all, cf KINK).
=> between HA and MN you should have a trusted third party
(provided through AAA) but I expect something better than
Kerberos.
I doubt that naive tunnel mode ESP really fits the
bill well here. There are a lot of concerns
about bits in the air that are quite serious
and using a tunnel would at base add another
40 bytes to the overhead. I'm also rather
suspicious about the contention that ROHC and
its ilk make tunnel/transport moot: there is a
huge amount of overhead and state machinery
to run compressors and counting on them --
especially when you start talking about mobile
routers -- is dubious at best.
=> tunnel mode ESP needs many improvements before to be usable
in a mobile environment (just try it or read my ID).
Maybe we ought to entertain Bruce Schneier's
suggestions. As far as I can recall, they
would seemingly address the concerns I outlined
above. Even if we don't try to deprecate
transport altogether, an out of band
negotiation of "the inner header is the same
as the outer header" compressing tunnel mode
would be pretty easy to cons up for ISAKMP.
=> before reread Bruce Schneier's document I can say the
transport mode as compressed tunnel mode really stinks
(argh! A new flame war? :-).
Regards
Francis.Dupont@enst-bretagne.fr
Follow-Ups:
References: