[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Protocol Action: Security Architecture for the Internet Protocol to Proposed Standard



The IESG has approved publication of the following Internet-Drafts as
Proposed Standard:

 o Security Architecture for the Internet Protocol 
	<draft-ietf-ipsec-arch-sec-07.txt>
 o IP Authentication Header
	<draft-ietf-ipsec-auth-header-07.xt>
 o The Use of HMAC-MD5-96 within ESP and AH 
	<draft-ietf-ipsec-auth-hmac-md5-96-03.txt>
 o The Use of HMAC-SHA-1-96 within ESP and AH 
	<draft-ietf-ipsec-auth-hmac-sha196-03.txt>
 o The ESP DES-CBC Cipher Algorithm With Explicit IV 
	<draft-ietf-ipsec-ciph-des-expiv-02.txt> 
 o IP Encapsulating Security Payload (ESP)
	<draft-ietf-ipsec-esp-v2-06.txt>
 o The Internet IP Security Domain of Interpretation for ISAKMP 
	<draft-ietf-ipsec-ipsec-doi-10.txt> 
 o Internet Security Association and Key Management Protocol (ISAKMP) 
	<draft-ietf-ipsec-isakmp-10.txt> 
 o The Internet Key Exchange (IKE)
	<draft-ietf-ipsec-isakmp-oakley-08.txt>
 o The NULL Encryption Algorithm and Its Use With IPsec 
	<draft-ietf-ipsec-ciph-null-01.txt> 


In the same action, the IESG also approved publication of the following
Internet-Drafts as Informational RFCs:

 o IP Security Protocol Working Group to consider IP Security Document
   Roadmap
	<draft-ietf-ipsec-doc-roadmap-02.txt>
 o The OAKLEY Key Determination Protocol
	<draft-ietf-ipsec-oakley-02.txt> 


These documents are the product of the IP Security Protocol Working
Group.  The IESG contact persons are Jeffrey Schiller and Marcus
Leech.

 
Technical Summary
 
These documents define a protocol for providing security services at the
IP (network) layer. Included are the basic packet formats, per packet
processing logic and key agreement and exchange methodology.


Working Group Summary


The IPSEC working group came to rough consensus around this set of
documents after numerous and often difficult debates. Consensus is
clear, however on the following points:


   * We need to deploy IP security now.
   * The protocol described works and is believed to be secure.
   * There is a market and demand for security at the IP layer.

Protocol Quality

The chief criticism of the work defined here is its complexity. However
complexity may not be avoidable in an attempt to provide general purpose
IP layer security protocol suite that can be used in many situations,
including those that scale to the size of the global Internet.

Multiple interoperable implementations of the protocol(s) described here
have been tested and some are in deployment.

Summary of Last Call Comments and AD Response

Two significant issues were raised during IETF Last Call. They are:


   * The Authentication Header (AH) protocol could have been designed
     differently so to make it easier to implement on some hardware
     platforms.

Response: Like many solutions to an engineering challenge, there are
often many approaches that may be chosen. Comparing options and
selecting the best is often influenced to the details of a particular
problem and the viewpoint of the engineer. The IPSEC working group
selected a particular solution and working group participants have
invested significant effort in defining it and in implementing it. The
comments raised in last call do not point to an obvious protocol defect,
but instead to a trade-off which the commenter would have made in a way
different then the working group. This was discussed explicitly at the
IPSEC working group meeting on April 3, 1998 and the consensus of the
working group was that AH should remain unchanged for now. I concur with
this reasoning.


   * IPSEC when used with encryption (ESP) makes it impossible for
     network monitoring tools to learn the TCP port numbers of Internet
     traffic so encrypted. Similarly performance enhancing schemes (such
     as ACK "spoofing") cannot be successful in the presence of IPSEC
     enhancements.

Response: This is not a defect in the protocols. Making packet tampering
and disclosure hard is exactly the goal of IPSEC! However there does
exist the higher level architectural question of how the trade-off is
made between security and the performance enhancements that may be
achieved by the technologies rendered difficult by the presence of
IPSEC. In situations where packet modification, such as ACK spoofing,
may result in performance gains, end-users will have to decide whether
they wish to sacrifice potential performance gains in favor of security.
Ultimately techniques need to be developed that permit security while
still providing appropriate performance. This work is beyond the scope
of the IPSEC working group and should not hinder the progress of the
work charted for the IPSEC working group.

In summary, I have considered the various Last Call comments and have
concluded that it is in the best interested of the Internet Community
for these documents to progress of Proposed Standard Status.

The IESG will look at the issue of acknowledgements and correct any
errors of ommission before advancing these documents to Draft Status.


                     -Jeff Schiller, Security co-AD

Note to RFC Editor:

The IESG requests the RFC Editor to make two changes in draft-ietf-ipsec-oakley-02.txt

1. The single occurance of MUST be lowercased.

2. Add the following to draft-ietf-ipsec-oakley-02.txt

   Security Considerations

     The focus of this document is security; hence security considerations
     permeate this memo.