[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Response to Last Call Comments for IPSEC Proposals
-----BEGIN PGP SIGNED MESSAGE-----
Response to Last Call Comments for IPSEC Proposals
(RFC1825-RFC1829)
Introduction
The IPSEC documents describe a security protocol for the IP
Layer of the Internet, both IPv4 and IPv6 are considered. These
documents have undergone our normal working group process and have been
in evolution for some years now.
Shortly before the Danvers IETF (April 1995) the documents
entered a period of "Working Group" Last Call. During the last call
period issues were raised and the documents evolved based upon comments
received. A rough consensus was reached.
The consensus was rough, not all parties to the discussions
completely agreed with the final forms of the documents, such is the
process of compromise and negotiation.
On June 22cd, the documents went to IETF last call prior to
being elevated to the status of "Proposed Standard." The purpose of IETF
last call is to give the community one last chance to review documents
and flag fatal errors that should prevent a document from advancing. It
is not a time to rehash the discussions that already took place within
the context of the working group. It is not a time to recommend delaying
progress in order to do a slightly better job.
We did receive a significant number of comments during the last
call. Many of these were supportive of the advancement of the document
set to Proposed Standard. However there were some comments that
recommended that we delay advancement and/or make major changes in the
direction of the work.
The purpose of this document is to answer those comments.
Rather than address each message individually, I will address the broad
category of complaints.
Complaint: The IETF should not mandate confidentiality mechanisms for
which vendors may have difficulty obtaining export approval from the
United States (and some other countries as well).
Response: This is an old complaint and one that the IESG, IAB and the
IETF as a whole have addressed numerous times. The clear consensus of
the community is that we must specify the best possible technologies
based upon the requirements of Internet users world wide. Weakening
of confidentiality in order to meet the arbitrary export requirements
of some governments is not appropriate.
Complaint: The document wording is ambiguous and some things could be
stated better.
Response: Indeed there is room for improvement in the particular wording
of the documents. However the IESG believes that the documented
*protocols* are sound and worthy of the implementation efforts that
spawn from a Proposed Standard RFC. All five documents still have two
important standardization steps to progress through ("Draft Standard"
and "Full Standard"). We fully expect that the document authors, in
cooperation with the working group, will take all such comments into
consideration. As these documents evolve through the standards
process they will likely become much better written, while still
essentially documenting the same (or only slightly modified)
protocols.
Complaint: You didn't pick the absolute best algorithm for each
function. Shortly, some new and/or better algorithms will be
available.
Response: In all endeavors there comes a time to "fish or cut bait." We
have to make progress to provide the security services that the
Internet community badly needs. No comment pointed out a fundamental
flaw or security breach in the current proposed protocols. Instead
comments were made that if we waited, we would get a little better
security.
The protocols provide for a choice of algorithms, so as better
algorithms become available, we can incorporate them into the
Internet Protocol Security standards with ease. But the IESG believes
that we can no longer wait. The security provided by these protocols
is more then adequate to meet the security challenges of the Internet
today.
The mandatory to implement algorithms are there to ensure a guarantee
of interoperability between differing implementations. However
implementors are free to implement other algorithms which end-users
are then free to use provided both end points of an association
implement a common set of algorithms.
Complaint: This is all very hard stuff and we should cogitate some more
on this subject.
Response: The Internet is no longer a research network. Most Internet
users view it as a service utility, one that is expected to be
reliable, available and secure. The lack of good security on the
Internet is a cause of great concern in many communities. These
documents specify a much needed IP Protocol level set of security
services, services that are urgently needed. The IESG believes that
very little will be gained and much lost from waiting any longer.
Summary
Although many valuable comments were received during the last
call period, none provided sufficient argument for the IESG to remand
the documents back to the IPSEC working group. However many of the
comments will influence the next versions of the documents as they
evolve through the standards process.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMDfnb8UtR20Nv5BtAQFAzgP5AfagaHxVRL6UJZjSe11CShR7naiGrNlN
ciIhH9S+ffxUBI8m/1Ogp7ERiMld5gO9KkCmU9OnRCVRi0/ue31tTvdlxmWYUHNL
guDQlD2/gAV8WFX7NqKI3PyPf+xgoHIjamNiZeIE8bbk37I3DI4Z2ZY3R1JjlCn6
1QP4OSr9f8w=
=MNc5
-----END PGP SIGNATURE-----