Ballot: Security Architecture for the Internet Protocol to Proposed Standard

IESG Secretary <iesg-secretary@CNRI.Reston.VA.US> Mon, 03 July 1995 17:51 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12499; 3 Jul 95 13:51 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12495; 3 Jul 95 13:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14400; 3 Jul 95 13:51 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12482; 3 Jul 95 13:51 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12478; 3 Jul 95 13:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14395; 3 Jul 95 13:51 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12445; 3 Jul 95 13:50 EDT
To: Internet Engineering Steering Group <iesg@CNRI.Reston.VA.US>
X-Orig-Sender: iesg-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary@CNRI.Reston.VA.US>
Reply-To: IESG Secretary <iesg-secretary@CNRI.Reston.VA.US>
Subject: Ballot: Security Architecture for the Internet Protocol to Proposed Standard
Date: Mon, 03 Jul 1995 13:50:45 -0400
X-Orig-Sender: scoya@CNRI.Reston.VA.US
Message-ID: <9507031350.aa12445@IETF.CNRI.Reston.VA.US>

NOTE: This is a multiple document set

Last Call to expire on: 06/30/1995

	Please return the full line with the vote.

		    Yes    No-Objection  Discuss *  Abstain

Harald Alvestrand   [   ]     [   ]       [   ]      [   ]
Scott Bradner       [   ]     [   ]       [   ]      [   ]
Joel Halpern        [   ]     [   ]       [   ]      [   ]
Frank Kastenholz    [   ]     [   ]       [   ]      [   ]
John Klensin        [   ]     [   ]       [   ]      [   ]
Deirdre Kostick     [   ]     [   ]       [   ]      [   ]
Allison Mankin      [   ]     [   ]       [   ]      [   ]
Paul Mockapetris    [   ]     [   ]       [   ]      [   ]
Mike O'Dell         [   ]     [   ]       [   ]      [   ]
Joyce K. Reynolds   [   ]     [   ]       [   ]      [   ]
Jeff Schiller       [ X ]     [   ]       [   ]      [   ]
Susan Thomson       [   ]     [   ]       [   ]      [   ]

 Yes =>     I have read the spec and know it is good stuff.
 No Obj =>  I am familiar with the protocol and believe it to be OK.
	    Note: The ballot contains analysis from the AD which
		  may be adequate information to vote positively.
 Discuss => There is something fishy that may need clarification
	    or modification. May be considered a "no" vote.
 Abstain => I am not familiar with the spec, have no
	    interest/expertise in the subject or otherwise feel
	    obliged to skip the voting.

 2/3 (8) Yes or No-Objection votes needed to pass.

 * Indicate reason if "Discuss".


To: IETF-Announce:;
Cc: RFC Editor <rfc-editor@isi.edu>
Cc: Internet Architecture Board <iab@isi.edu>
Cc: ipsec@ans.net
From: The IESG <iesg-secretary@cnri.reston.va.us>
Subject: Protocol Action: Security Architecture for the Internet Protocol
	 to Proposed Standard
-------------

The IESG has approved the Internet-Drafts  as a Proposed Standards:

1. Security Architecture for the Internet Protocol
	<draft-ietf-ipsec-arch-02.txt>
2. IP Authentication Header <draft-ietf-ipsec-auth-02.txt>
3. IP Encapsulating Security Payload (ESP) <draft-ietf-ipsec-esp-01.txt>
4. IP Authentication using Keyed MD5 <draft-ietf-ipsec-ah-md5-03.txt>
5. The ESP DES-CBC Transform <draft-ietf-ipsec-esp-des-cbc-04.txt>


These documents are the product of the IP Security Protocol Working
Group. The IESG contact person is Jeffrey Schiller.

Technical Summary

  These documents specify mechanisms for providing Authentication,
  Integrity, and Confidentiality of data traveling at the IP (both IPv4
  and IPv6) layer. Although not intended as a replacement for security
  services at other layers of the protocol stack, this technology
  provides significant benefit to the many applications that today use
  the network with little or no security protection.


Working Group Summary

  After an extended period of discussion and debate, the Working Group
  has come to consensus around these five documents. More work remains
  to be done, including the development of an Internet key management
  protocol, which the working group is currently addressing. Although
  an automated key management protocol is not yet specified, the above
  documents do not require a specific mechanism, by design. As such
  they are implementable as they stand.

Protocol Quality

  Jeff Schiller reviewed these protocols for the IESG. The need for
  security services on the Internet is now well known and these
  protocols provide an effective and in many cases transparent solution
  for many of the Internet Security problems we are experiencing today.
  Several implementations are currently underway and there is high
  confidence that these protocols will operate properly.