- Stefan
-----Original Message-----
From: Steve Bellovin [mailto:smb@research.att.com]
Sent: Wednesday, January 27, 1999 6:35 PM
To: ipsec@tis.com; end2end-interest@ISI.EDU; tsv@ee.lbl.gov;
diff-serv@baynetworks.com; ecn-interest@research.att.com;
red-impl@lbl.gov
Cc: jis@mit.edu; mleech@nortel.ca
Subject: transport-friendly ESP
I've set up a new mailing list, tf-esp@research.att.com, to discuss the
design of a transport-friendly variant of ESP (a core piece of IPSEC).
Subscription is via majordomo@research.att.com.
The problem is that ESP, by hiding all of the TCP (and UDP) headers,
makes
life difficult for other purposes, such as discerning flows, building
firewalls, etc. Can we come up with a variant of ESP that -- optionally
-- leaves some of the packet header in the clear?A strawman proposal can be found in http://www.research.att.com/~smb/talks/mesp .ps or http://www.research.att.com/~smb/talks/mesp.pdf (content is the same). It leaves an indicated amount of the prefix in the clear. It's reasonably efficient in both space and time. However, it is based on the tacit assumption that the prefix of the packet headers are the least significant from a security perspective -- is this true? Do we need a more complex format that permits individual fields or ranges to be in the clear? How do we prevent careless leakage of sensitive data? For example, if the TCP checksum is exposed, an enemy can read all one- and two-byte payloads. How is this negotiated? It can't be a simple length, since that doesn't take into account UDP vs. TCP, IP options, IPv6 headers, etc. Is there any need to permit controlled modifications to packets? If so, how do we protect against nasty changes?
Apart from discussing these questions on the list, we need to decide if we want to hold a BoF in Minneapolis. If the answer is yes, we'd also need to write up a charter and select chairs, preferably one from the security area and one from the transport area. Nominations are hereby solicited. The output of an eventual tfesp working group would be two or three RFCs -- standards-track RFCs to define the new header, to define the additions to IKE to negotiate use of this modified format, and possibly an informational RFC setting out the rationale for the change -- and the security caveats that would attend its use.