Messages in this thread | | | Subject | Re: tcp/ip bug (2.2.12) or telnet client bug | Date | Mon, 27 Sep 1999 13:21:44 -0700 | From | Craig Milo Rogers <> |
| |
>> > Confirmed that version 2.3.13 has that bug also. > >Its not a bug > >> so do ./stest 1316 and it connects... >> this is not meant to happen as far as I know ... > >RTFRFC > >yes it is supposed to happen.
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/
| |