1
0
mirror of https://github.com/opsxcq/mirror-textfiles.com.git synced 2025-08-11 17:34:31 +02:00
Files

123 lines
3.6 KiB
Plaintext
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Date: 30 Nov 1983 0310 PST
From: Eric P. Scott <EPS at JPL-VAX>
Reply-To: EPS at JPL-VAX
To: TCP-IP at SRI-NIC
Re: Not an RFC inspired by a somewhat infamous computer game
Network Hacking Group E. P. Scott
Request for Kludges: XXX JPL
November, 1983
Updates: RFC 821
SMTP POLYMORPH COMMAND
Preface
The purpose of this document is to present a partial workaround for
an anticipated future problem in the ARPA Internet. It is hoped that
it will prove unnecessary to adopt such an overtly ridiculous
strategy as a practical means of preserving connectivity. The views
expressed are the author's own and do not necessarily reflect those
of NASA, the Jet Propulsion Laboratory, or the California Institute
of Technology. Treat them as satirical in nature.
Introduction
Current plans call for the activation of "access control filters" in
the six IP gateways that bridge MILNET and ARPANET on February 1,
1984 [1]. In most cases communications will be restricted to mail
only. Sites such as ours which are in the wrong Community Of
Interest vis a vis the sites they need to communicate with because
the politics run counter to legitimate research needs will be unable
to participate as functional nodes after this date. A trivial
solution is of course to abandon the plan to segregate the two
networks [2]. Assuming that this does not happen and the controls go
into effect on schedule, it will be necessary to defeat the
"protection" offered in order to "stay in business" (unless the
Powers That Be can be convinced to put us back on the other side of
the fence before then). Even so, other sites share a similar plight.
Description
I propose to implement an extension to the SMTP protocol [3] that
would allow services such as Telnet [4] to be accessed via port 25.
The extension consists of the new command POLY which accepts as its
parameter a keyword identifying the service desired. Successful
execution of POLY returns a 250 reply and replaces the SMTP server.
It is assumed that POLY would be given as the first command in a
session in order to avoid considering the implications of arbitrary
placement. A typical scenario might look like:
@TELNET
TELNET>INTERNET (HOST) JPL-VLSI (ON PORT) 25
Trying... Open
220 JPL-VLSI.DDN SMTP Service
POLY TELNET
250 Toto, I don't think we're in SMTP anymore!
JPL VLSI Design Center VAX...
Scott [Page 1]
SMTP Polymorph Command RFK XXX
Syntax
POLY <SP> <string> <CRLF>
Replies
S: 250
E: 500, 501, 502, 503, 504, 421
Concluding Comments
"Polymorph" commands are nothing new; SMTP's TURN can be considered
one; perhaps a better example is the Telnet SUPDUP Option [5].
FTP presents a special problem since data is not transmitted over
the telnet connection.
This won't help (most) TAC users.
References
[1] DDN Program Management Office, "Further Details on the MILNET/
ARPANET Split," in DDN Newsletter no. 28, Network Information
Center, SRI International, July 1983.
[2] Muuss, M., "On the Undesirability of `Mail Bridges' as a
Security Measure," in TCP-IP Digest, vol. 2, no. 18, BRL,
October 1983.
[3] Postel, J., "Simple Mail Transfer Protocol," RFC 821, USC/
Information Sciences Institute, August 1982.
[4] Postel, J. and J. Reynolds, "Telnet Protocol Specification,"
RFC 854, USC/Information Sciences Institute, May 1983.
[5] Crispin, M., "Telnet SUPDUP Option," RFC 736, NIC 42213,
Stanford Artificial Intelligence Laboratory, October 1977.
Scott [Page 2]