[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Last Call for IPSEC
IESG members,
My recommendation to the IESG is to pass all BUT the IPSEC Architecture
document to PS as requested by the working group(I am including AH in this).
This allows all vendors to claim IETF proposed standards compliance with
their products. The architecture document should follow when experience
with IPSEC fleshes out and can catch up in the standards process at the time
for movement to Draft standard. The ISAKMP documents will need to be
changed to address peer recovery - see below.
My understanding is that you will all be sitting down to discuss the last
call for IPSEC in the immediate future. I am asking you to consider the
issues I have raised with the collection protocols proposed to date. To
recap: 1) AH is technically flawed (and not needed for IPv4, and it is
dubious in the context of IPv6), 2) the system (IPSEC + ISAKMP) as it is
currently defined is not sufficiently robust in light of failure of a peer
(the net result is that people will have to crank their Security Association
timers down to a ridiculous interval), and 3) calling anything the Internet
Key Exchange (IKE) should not happen since there are many Internet Key
Exchanges going on in the Internet today and several are being standardized
by Internet working groups(e.g TLS).
IPSEC is a critical and important set of standards and it should be done
well, the first time.
The collection of standards and the "MUSTS" in the IPSEC Architecture
document make the minimal standards compliant implementation very large.
For example: AH+ESP, tunnel+transport modes, DES+NULL+3DES, SHA+MD-5,
Manual+Certs, result in way to many options mandated for managing the system
in the Architecture doc. My concern here is that the value of the standard
will be deprecated when vendors building small minimal implementations will
elect to subset from this long list. If I were to build the Internet
toaster I would not build in everything mandated (MUSTs) in the current
collection of drafts you are reviewing (When Peter Ford is using the word I
in this piece of email, Peter Ford is talking from a personal perspective,
not that of the Microsoft Corporation).
The working group process to date has been turbulent but relatively fair.
I thank the chairs and the Area director for the opportunity to raise and
discuss my concerns at the LA IETF. The outcome of those discussions was to
move the documents forward as is. The dominant reason expressed: 1) we have
working interoperable implementations of AH, 2) the working group has
already discussed AH and its flaws, but several people felt it is a MUST for
IPv6, most people agree that it is not useful for IPv4, 3) that if we
deliberate further IPSEC will be delayed and the market will be delayed as a
result. 1) is not a reason for standardization, it is a requirement for
standardization. 2) is a sorry state to be in due to the coupling of IPv4
and IPv6 in several standards (a mistake ...) 3) the market demand for
IPSEC is high and most vendors in the room are already selling something
they label as IPSEC compliant in some manner.
The issue of peer recovery was not addressed in the working group since the
topic was not put on the agenda by the working group chairs. This needs to
be addressed. Host vendor implementations should address this issue prior
to deployment (I know of one implementation in beta that does not do this
and the vendor is sorry about it).
It is critical to get the standards document process for IPSEC kicked off.
Thus my recommendation at the top of this note is a measured approach that
should meet the needs of vendors, implementators and the market in general.
Some might be surprised I am recommending standardization of AH. The
standards are meant to guide implementations so we get Interoperability
between implementations. AH should be built in an interoperable manner.
Having a standard for AH is all well and good.
Cynics in the audience recommended to me that I should simply ignore the
process and implement whatever is needed: "that is what everyone else will
do". My desire is to get the documents fixed. I hope others share my
optimism in making the standards process result in good standards. One
reason we have rules of governance in societies to provide measured and
proper oversight.
with regards,
Peter S. Ford - peterf@microsoft.com
Follow-Ups: