2.6.4 IP Security Protocol (ipsec)

NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98


Theodore Ts'o <tytso@mit.edu>
Robert Moskowitz <rgm@icsa.net>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortel.ca>

Security Area Advisor:

Jeffrey Schiller <jis@mit.edu>

Mailing Lists:

General Discussion:ipsec@tis.com
To Subscribe: ipsec-request@tis.com
Archive: ftp://ftp.tis.com/pub/lists/ipsec OR ftp.ans.net/pub/archive/ipsec

Description of Working Group:

Rapid advances in communication technology have accentuated the need for security in the Internet. The IP Security Protocol Working Group (IPSEC) will develop mechanisms to protect client protocols of IP. A security protocol in the network layer will be developed to provide cryptographic security services that will flexibly support combinations of authentication, integrity, access control, and confidentiality.

The protocol formats for the IP Authentication Header (AH) and IP Encapsulating Security Payload (ESP) will be independent of the cryptographic algorithm. The preliminary goals will specifically pursue host-to-host security followed by subnet-to-subnet and host-to-subnet topologies.

Protocol and cryptographic techniques will also be developed to support the key management requirements of the network layer security. The Internet Key Management Protocol (IKMP) will be specified as an application layer protocol that is independent of the lower layer security protocol.The protocol will be based on the ISAKMP/Oakley work begun in:


draft-ietf-ipsec-oakley-01.txt, and


A follow on work item may incorporate mechanisms based on SKIP as defined in:


and related documents.Flexibility in the protocol will allow eventual support of Key Distribution Centers (KDC), such as are used by Kerberos.

Goals and Milestones:



Post as an Internet-Draft the IP Security Protocol.



Post as an Interenet-Draft the specification for Internet key management.



Submit the Internet Key Management Protocol to the IESG for consideration as a Proposed Standard.



Conduct initial interoperability testing of Encapsulating Security payload (ESP) and Authentication Header (AH).



Submit revised Interent-Drafts for ESP, AH, and IP Security Architecture.



Submit revised Internet-Drafts of IP Security Architecture, ESP, and AH to the IESG for consideration as Draft Standards.

Dec 96


Submit revised Internet-Drafts of IP Security Architecture, ESP, and AH to the IESG for consideration as Draft Standards.



Submit Internet-Draft of the Internet Key Management Protocol (IKMP) based on ISAKMP/Oakley to the IESG for consideration as a Proposed Standard.



Submit Internet-Draft of Internet Key Management Protocol to the IESG for consideration as a Proposed Standard.

Jul 97


Submit IKMP to IESG for consideration as a Draft Standard.


Request For Comments:






IP Authentication using Keyed MD5



IP Authentication Header



Security Architecture for the Internet Protocol



IP Encapsulating Security Payload (ESP)



The ESP DES-CBC Transform



HMAC: Keyed-Hashing for Message Authentication



HMAC-MD5 IP Authentication with Replay Prevention

Current Meeting Report

Chicago IETF (August, 1998) IPsec Working Group Meeting Minutes

The WG met on Tuesday at the IETF meeting in Chicago, from 14:15 to 15:15.
Approximately 120 people attended. This was MBONE broadcast.

The Agenda was:

* Workgroup status
* Workshop announcement
* Charter revision
* Discovered problems with Ipsec/IKE based on current implementation experience ---
Lifetime discussion
* ICMP messages, standardized error codes, and MIBs
* Policy/tunnel endpoint discovery
* Policy-based Security Management

Workgroup status

Ted gave a report on the status of the IPSEC working group. The full suite of Internet
Drafts have been approved by the IESG. They are currently being processed by the
RFC editor and should be published shortly. It is now time to revisit the IPSEC charter
since we have met almost all of the goals and milstones in the original charter.

Workshop announcement

Microsoft will be sponsoring an IPSEC interoperability testing workshop in Redmond
on Aug 31 -- Sep 3rd. Approximately 20-25 companies have signed up for the workshop.
William Dixon (wdixon@microsoft.com) is the contact person for this workshop.

IBM is also sponsoring another round of interoperability testing in Binghamtom, NY
on October 27--30. This test will also include L2TP. The $300 fee has been waived
by IBM.

Charter revision

Bob Moskowitz led a discussion on new items for work goals for revising the charter.
These items included:

* address errors and improvements; errata to be maintained on MIT web site
* add functionality
* remote client support

* policy and tunnel endpoint discovery (Bill Simpson votes to remove, since this is a
complex non-security issue already being dealt with elsewhere)
* complex tunnel management
* ICMP messages, error codes, MIBs
* Additional algorithms
* IPsec over non-IP protocols (IPX? "Running shoes?")
* Key recovery: excluded to the sound of cheers and hisses
* Integration of IPsec and certificate frameworks, DNSsec
* Cleaning up the host-host (non-VPN) case; not sure what's missing
* results implemented from Secure Multicast IRTF activity

The working group chairs will compose a new proposed charter based on these
suggestions, and present it to the working group.

Lifetime discussion

Although there is a default value established for Phase 2 lifetimes, there is no similar
default for Phase 1 lifetimes. There is unfortunately is conflicting interpretations
regarding how to proceed in the absence of an explicitly specified PHase 1 lifetime.
There is an optional notification facility, but it's unclear what happens if the notified
value ins't acceptable. There is an interoperability impact caused by this
underspecification. (This will need to be corrected in a protocol errata.)

ICMP messages, standardized error codes, and MIB's

Michael Richardson gave a presentation on a two problems which he has been
concentrating on. One is the issue of Path MTU discovery across a IPSEC tunnel;
which could be ignored in IPV4, but not in IPV6. (Since IPV6 drops packets greater
than the MTU, instead of fragmenting them; on the other hand, the IPV6 minimum
MTU is also much bigger, so perhaps the problem can be ignored).

The other area of concern is ICMP messages and IPSEC, to support diagnostic tools
such as traceroute and PING.

Policy/tunnel endpoint discovery

Roy Perieira has some drafts forthcoming which will cover IPSEC policy and tunnel
endpoint discovery issues. These include how a new machine on the network
bootstraps itself by obtaining its first policy, and secure route discovery in the face of
complex topologies and multiple secure paths for load-balancing and/or redundancy.

Policy-based Security Management

Luis Sanchez gave a presentation on some Security Policy Management going on at BBN.
(Slides included)


Policy Based Security Management for IPSec

Attendees List

go to list