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

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.




Follow-Ups: