Here is my position on this problem. I welcome discussion,
although we should take it offline, I think.
Statement of Problem
========= == =======
When the application opens a TCP connection without specifying
a local port number, the system will sometimes assign the same
local port number as the foreign port number in the connection,
creating an open, looped connection if the local and foreign IP
adresses are the same. The application programmer expected the
connection to fail, as the specified "foreign" port did not
exist prior to the attempt to open the "local" port and connection.
Note that the question isn't, "Should explicitly requested TCP
self-connections be allowed?". Rather, it is, "Should unintentional
TCP self-connects be prevented?"
References
==========
The two current RFCs governing TCP behavior in this area are:
RFC793 Transmission Control Protocol
RFC1122 Requirements for Internet hosts - communication layers
Analysis
========
The closest thing to a statement about allocating ports in
general is in RFC 793 section 2.7:
TCPs are free to associate ports with processes however they choose.
In this sense, the present Linux TCP behavour is allowed by the
RFC. :-) On the other hand, the Robustness Principle (RFC 1122 section
1.2.2) should also be taken into consideration; although it is
described in terms of packet processing, it can be applied in other
areas.
RFC 1122 section 4.2.2.1 divdes the port space into the
well-known ports, the reserved port range of some implementations, and
the remainder of the port space. I don't see any particularly
pertinent constraints here.
RFC 793 section 3.8 discusses the minimum required functional
interface btween the "user" (the application program) and the
system-level TCP implmentation. The key point here is that, in all of
the connection opening interfaces illustrated in the RFC, the local
port number is allocated by the application program rather than by the
system-level TCP code. RFC 1122 continues the use of the "application
allocates the port" model.
So, is the self-connect behavior supposed to happen, according
to the RFCs? I could answer, "No, it is not supposed to happen", on
the grounds that the RFCs do not illustrate the system-level TCP
implementation allocating the local port in the first place. That
would be misstating the intent of the RFCs, though: additional
functionality is permitted in the TCP API, so long as the minimum
functionality is provided.
In conclusion, the current RFCs do not address the issue of
whether opening a TCP connection using an system-assigned local port
should be allowed to create a self-connection.
Personal Experience
======== ==========
Given that the RFCs are silent on the issue of preventing
unintentional self-connects that may occur through system-level local
port assignment, one can ask more subjective questions, such as, "what
id the TCP designers intend?" or "what is common practice?". I offer
the following personal experience:
In the early 1980's, the BBN Tenex/TOPS-20 TCP/IP
implementation was considered the reference standard. My memories are
vague, and I don't have sources handy anymore, but I believe it had
the feature of allowing the system to assign the local port number in
a connection opening request. I believe that, when reading the BBN
TCP sources, I came across a line of code that refused to dynamically
generate a local port number that matched the foreign port number in
the request. I discussed this line with jon, and he said that the
intent was to prevent unintentional self-connects.
Conclusions
===========
The RFCs do not address the issue of whether unintentional
self-connects should or should not be allowed; the RFCs do not address
the particular application API details that cause the existance of the
problem. The Robustness Principle, and personal experience, lead me
to believe that unintentional self-connects should be prevented, as
prevention is cheap and does not change any of the explicitly required
system functionality.
Of course, I think that the Robustness Principle also implies
that a port scanning program should explicitly allocate a fixed local
port before performing this sort of activity.
Craig Milo Rogers
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/