Subject: (NAT) transport-friendly ESP (fwd)

From: Rhandeev Singh <[email-masked]>
Date: Fri, 29 Jan 1999 12:06:05 +0800 (SGT)

I'd like to call attention to the "transport-friendly ESP" discussion
going on at the IPSEC list, and the new tf-esp list.

While RSIP shouldn't have problems with the existing ESP architecture, the
implications of a transport-friendly ESP with respect to conventional NAT
loom great before us.

---
Rhandeev Singh                          [email-masked]
Linux User Group                        http://linux.comp.nus.edu.sg
School of Computing                     http://www.comp.nus.edu.sg
National University of Singapore

---------- Forwarded message ----------
Date: Wed, 27 Jan 1999 21:34:35 -0500
From: Steve Bellovin <[email-masked]>
To: [email-masked], [email-masked], [email-masked],
    [email-masked], [email-masked],
    [email-masked]
Cc: [email-masked], [email-masked]
Subject: transport-friendly ESP

I've set up a new mailing list, [email-masked], to discuss the
design of a transport-friendly variant of ESP (a core piece of IPSEC).
Subscription is via [email-masked].

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.

-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 29 Jan 1999 07:28:10 -0500

In message <[email-masked]
>implications of a transport-friendly ESP with respect to conventional NAT

Right.  Please note, though, that my proposal does not help NAT, since
I don't know how to permit changes to the packet and still prevent attacks.

-