This seems extremely relevant to both PILC and RUTS - I heard about it
during a hallway conversation in Orlando, and am glad to see the details.
I note that the flame-fest has started on the original mailing lists - if
you are interested in participating, you probably want to join one or more
of them to follow the fun!
Spencer
> -----Original Message-----
> From: Steve Bellovin [SMTP:smb@research.att.com]
> Sent: Wednesday, January 27, 1999 8: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; Leech, Marcus [FITZ2:8M70-I:EXCH]
> 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.
>
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:20 EST