If you switched from TCP to UDP, you can throw things out without needing a reply, but that’s a whole different protocol.
Yes, a typical “stateful” firewall will see the initial SYN and add an entry to its list of active connections, detailing the source and destination port and address. It will then know to accept the replies back to that port. Under UDP, which has no notion of established connections, things are a little trickier. The firewall must monitor UDP traffic and assume that replies to a port that was recently used as a source port are part of the same session.
Consider my ignorance fought! Thanks everyone! The “firewall automatically opens the return port” bit really helps everything make sense.
In college, maybe. OSI lost to TCP/IP in the 1980s and the IETF thinks that layering should be Considered Harmful. Even if you think layering is mostly useful, as I do, the TCP/IP model uses four or, at most, five layers, not the seven of OSI. Why the OSI model is still taught is a mystery to me.
I’m not sure what you mean by “OSI lost to TCP/IP” - one is the actual implementation of a protocol suite, whereas the other is a conceptual tool to think about network structures.
The model is taught because it helps to explain what’s done with network traffic at every point - from the high-level protocols like HTTP all the way down to how network nodes are addressed by MAC address.
Regarding the thread title, I could swear Goldie Hawn or Judy Carne asked that same question on Rowan and Martin’s Laugh-in.
The OSI protocol suite lost to the TCP/IP protocol suite. We use SMTP to send email, not X.400.
But it doesn’t do a very good job because the TCP/IP protocols weren’t designed with that layering in mind. Quick: In TCP/IP, what protocols are used for the Presentation layer as distinct from the Application layer? What is the justification for strict separation of Data Link and Physical when many Data Link protocols are irrevocably tied to specific Physical Layers (fiber optics and SONET, for example)?
OK, better example: What is the Physical layer beneath 802.11?
Well, there’s the 2.4 GHz band, the 5.8 GHz band, or you can communicate via IR.
What do I win?
Anyway, SenorBeef said conceptual. It’s used as an abstraction to help people learn about the different functions provided by the network and how they interrelate. Whenever the OSI model is taught everybody just waves their hands and says that nobody bothers with a separation of the presentation, session and application layers.
lol…wonder why. 
Great thread btw. I was just looking in and wanted to say that this question was answered pretty well. I have customers ask me stuff like this all the time and I’m going to put this in my library of links for good explanations they can use so I don’t have to. Kudos.
OSI is still taught because it allows people to segregate what is going on and to compartmentalize the process. Nearly every network engineer I know thinks in terms of the model (or at least in terms of the model and how it relates to TCP/IP).
-XT
In layman’s terms. Consider the IP address a phone number and the port as the extension at that number. Different services (or offices in this example) answer to calls to their ports.
Basic web pages are at port 80.
FTP file transfer services are at 21.
Telnet operates on 23.
email is on 25.
The end user doesn’t have to worry about them because the application they’re using knows the default settings and tries them automatically.
A fairly complete list is here if you’re interested. There are literally thousands of standard assignments, the majority of which are totally irrelevent to the average user.
But 802.11 extends down that far. Therefore, it straddles two OSI layers, something a protocol isn’t supposed to do if the OSI model were even mostly valid.
Which is my point entirely. We should teach something similar to the four-layer model as mentioned in RFC 1122: link, IP, transport, and application. Physical layer gets folded into link and application encompasses all of the high-level stuff.
I’m not against teaching layering, but we should ditch the OSI model and always teach that layers are far from absolute.
A follow-up question occurs to me:
When a firewall automatically accepts return traffic (Process A inside firewall connects to process B outside. A sends on 7777, B replies on 30777, for example.), is there a limitation on what messages the firewall will automatically pass inside? It would seem reasonable that only ACK messages and such would be allowed, otherwise process B could hack into the protected area?
I’m not quite sure what you mean by “hack into the protected area”, but anyway I guess I should have said that the firewall will consider the connection established after the SYN - SYN/ACK - ACK handshake has completed. Stray SYN/ACKs and ACKs that don’t correspond to earlier SYNs or SYN/ACKs would be blocked from reaching the destination by a TCP-aware firewall.
A process outside the firewall might be able to send any message on the automatically opened return port (30777 in my example) which might cause the sending process (process A in my example) to do unpleasant things.
To clarify my example, let’s take a specific case. I “open” (send a message) to 12.13.14.15 (outside my corporate firewall) on port 80. The process there, listening on port 80, sends an ACK on whatever random port my process is listening on. Port 80 outbound is open because my company finds it useful for me to access web servers outside the firewall. The return port is open because the firewall automatically opened it when I did the “open” call.
I believe I’m OK so far?
Now, that process out there in cyberspace, outside my firewall, might send some other message, telling my process to explode or delete files or expose critical information, mightn’t it? I’m suggesting that the firewall might only allow the ACK message but disallow other types of communication on that automatically-opened-random-port. Does it?
Well, presumably you established the connection to do something useful, such as viewing a web page. So once the connection is established, the firewall will wave through the actual data packets, such as those containing HTTP.
What the process does with the data is not the firewall’s concern, but presumably the person who wrote the code knew what sorts of messages were allowed under the protocol in question, and wouldn’t just make the process blindly obey random commands like “wipe the hard disk”, even if such commands were part of the protocol, which seems unlikely. The poiint is, the remote computer can’t just send any instructions it likes to your computer. Your computer will only react to instructions that it is programmed to react to. Anything else is meaningless to it.
Of course, there are sometimes bugs which inadvertently allow the client to be fooled into doing undesirable things.