>Tunnelling is a very useful mode. It's most useful for routers, >bump-in-the-stack encryptors, IP forwarding (e.g. IP >``remailers''), and perhaps also firewalls...but I don't >think the utility is limited to those situations. >It's important that implementors realize they must support this mode >of operation. The intent has always been to mandate support in all implementations of both "end-system" and "router-like" (a.k.a. firewalls, intermediate systems, etc.) signaling. Several approaches are viable to support the necessary remapping of addresses and the group has had a strong consensus on the use of the "tunneling" (e.g. IP/ESP/IP) to provide this functionality. Obviously minor tweaks in the next release of the specification could help clarify these interoperability requirements. Paul PS - Implementations that allow multiple encapsulation (ESP/ESP/IP, or ESP/ESP/ESP/IP, etc.) may not be exportable as a product from the US. Exportable implementations may be required to block ESP over ESP :-( -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com --------------------------------------------------------------
-- BEGIN included message
- To: Phil,Karn,karn@qualcomm.com
- Subject: Re: ICMP Security Failures
- From: "David Wagner" <daw@cs.berkeley.edu>
- Date: 20 Dec 95 02:26:20
- Cc: ipsec@ans.net
> >I'd like to expunge use of the terms "transport-mode" and >"tunnel-mode" from IPSEC documents. Not because the modes they >describe aren't useful, but because I really consider them completely >orthogonal to the security mechanisms IPSEC provides. > Hrmm, I don't have any comments on the wisdom of this change, but... Even if the words "transport-mode" and "tunnel-mode" are expunged, I hope the documents will clearly explain this type of usage and its importance somewhere. Tunnelling is a very useful mode. It's most useful for routers, bump-in-the-stack encryptors, IP forwarding (e.g. IP ``remailers''), and perhaps also firewalls...but I don't think the utility is limited to those situations. It's important that implementors realize they must support this mode of operation. The tunnel/transport modes aren't orthogonal, from the implementation perspective: to support tunnel-mode, the IPSEC modules must be re-entrant, and must deal with remembered security state when processing IP headers. Implementors probably won't think to support all this if it's not described explicitly in the spec.
-- END included message