Identifying ESP-NULL Packets
draft-bhatia-ipsecme-esp-null-00

 
Document Type Expired Internet-Draft (individual)
Last updated 2008-12-01
Stream (None)
Intended RFC status (None)
Formats
Expired & archived
plain text pdf html
Stream Stream state (No stream defined)
Document shepherd No shepherd assigned
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-bhatia-ipsecme-esp-null-00.txt

Abstract

Encapsulating Security Payload (ESP) [RFC4303] provides data integrity protection, confidentiality and data origin authentication for data transported in an IP packet. There are various applications and protocols that do not require confidentiality but only need data integrity assurance or data origin authentication. Since ESP support is mandatory for IPSec, such applications end up using ESP with NULL encryption. However, because of the way ESP is defined, it is impossible for firewalls and intermediate routers to differentiate between encrypted ESP and ESP NULL packets by simply examining them. This poses problems for the firewalls since such packets cannot be filtered and identified. It poses a different set of problems for routers since such packets cannot be properly filtered, classified and prioritized. This document proposes an extension to ESP so that firewalls and routers can disambiguate between ESP encrypted and ESP NULL encrypted packets.

Authors

Manav Bhatia (manav@alcatel-lucent.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)