[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-----