Subject: [midcom] [Fwd: RFC 3093 on Firewall Enhancement Protocol]

From: Jiri Kuthan <[email-masked]>
Date: Mon, 02 Apr 2001 13:14:58 +0200

The attached RFC seems to be of tremendous relevance to midcom.

Jiri

RFC Editor wrote:
> 
> A new Request for Comments is now available in online RFC libraries.
> 
>         RFC 3093
> 
>         Title:      Firewall Enhancement Protocol (FEP)
>         Author(s):  M. Gaynor, S. Bradner
>         Status:     Informational
>         Date:       1 April 2001
>         Mailbox:    [email-masked], [email-masked]
>         Pages:      11
>         Characters: 22405
>         Updates/Obsoletes/SeeAlso:  None
> 
>         URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3093.txt
> 
> Internet Transparency via the end-to-end architecture of the Internet
> has allowed vast innovation of new technologies and services [1].
> However, recent developments in Firewall technology have altered this
> model and have been shown to inhibit innovation.  We propose the
> Firewall Enhancement Protocol (FEP) to allow innovation, without
> violating the security model of a Firewall.  With no cooperation from
> a firewall operator, the FEP allows ANY application to traverse a
> Firewall.  Our methodology is to layer any application layer
> Transmission Control Protocol/User Datagram Protocol (TCP/UDP) packets
> over the HyperText Transfer Protocol (HTTP) protocol, since HTTP
> packets are typically able to transit Firewalls.  This scheme does not
> violate the actual security usefulness of a Firewall, since Firewalls
> are designed to thwart attacks from the outside and to ignore threats
> from within.  The use of FEP is compatible with the current Firewall
> security model because it requires cooperation from a host inside the
> Firewall.  FEP allows the best of both worlds: the security of a
> firewall, and transparent tunneling thought the firewall.
> 
> This memo provides information for the Internet community.  It does
> not specify an Internet standard of any kind.  Distribution of this
> memo is unlimited.
> 
> This announcement is sent to the IETF list and the RFC-DIST list.
> Requests to be added to or deleted from the IETF distribution list
> should be sent to [email-masked].  Requests to be
> added to or deleted from the RFC-DIST distribution list should
> be sent to [email-masked].
> 
> Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
> an EMAIL message to [email-masked] with the message body
> help: ways_to_get_rfcs.  For example:
> 
>         To: [email-masked]
>         Subject: getting rfcs
> 
>         help: ways_to_get_rfcs
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to [email-masked].  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.echo
> Submissions for Requests for Comments should be sent to
> [email-masked].  Please consult RFC 2223, Instructions to RFC
> Authors, for further information.
> 
> Joyce K. Reynolds and Sandy Ginoza
> USC/Information Sciences Institute
> 
> ...
> 
> Below is the data which will enable a MIME compliant Mail Reader
> implementation to automatically retrieve the ASCII version
> of the RFCs.

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

From: Andrew Molitor <[email-masked]>
Date: Mon, 2 Apr 2001 12:36:02 -0500 (CDT)

> > A new Request for Comments is now available in online RFC libraries.

	This would be a lot funnier if IP over SMTP hadn't actually
been implemented, for essentially the reasons indicated, albeit in a
much simpler way. As biting satire, it's pretty effective, if slightly
spooky ;)

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 02 Apr 2001 13:17:08 -0500

> much simpler way. As biting satire, it's pretty effective, if slightly

So has IP over HTTP.

   Brian