Solicited vs. Unsolicited TCP/IP packets. How do they differ?
Elton
Can someone help me with an article/tutorial/post, or explain me the
details of the mechanisms that make the difference between solicited
and unsolicited packets?
Ersek, Laszlo
"Solicited" is a human concept. If you "cron" or "at" a program on a
remote machine via ssh, then log out, so that it tries to connect back to
your desktop sometime(s) later, that is "solicited", but your desktop's
firewall (if set up correctly) won't look at it as such until you tell it.
lacos
Elton
I was asking more about details how does it works from the OSI layers
perspective.
Jorgen Grahn
TCP is not based on the OSI model, so that can be tricky.
(As far as I know it doesn't use the terms "solicited" and
"unsolicited" either. What is the context? Google seems to indicate
that it's a term used in error messages from home firewall software.)
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Elton
This post could clarify the problem's context a bit more:
http://groups.google.com/group/alt.comp.networking.connectivity/browse_thread/thread/026943d6323f1801/ebaf12cf882ea29f
The main question is: Where and how do the solicited and unsolicited
inbound traffic differ from each other?
And also: How do ISP's who block unsolicited inbound traffic on home
customers computers ports, distinguish it from solicited inbound
traffic?
Jorgen Grahn
> This post could clarify the problem's context a bit more:
> http://groups.google.com/group/alt.comp.networking.connectivity/browse_thread/thread/026943d6323f1801/ebaf12cf882ea29f
As far as I can tell, it's just some guy on
alt.comp.networking.connectivity using the word "solicited" like this:
Solicited traffic is traffic that's in response to something you
initiated on your end, like clicking a web link or logging into your
email server to send or retrieve email. Unsolicited traffic is not
in response to a request. The mechanics of how the packets differ
assumes some detailed knowledge of the 7 layer OSI model and might
be more than you want to know.
I must say I have no precise idea what he's talking about, especially
in that odd reference to the OSI model.
> The main question is: Where and how do the solicited and unsolicited
> inbound traffic differ from each other?
> And also: How do ISP's who block unsolicited inbound traffic on home
> customers computers ports, distinguish it from solicited inbound
> traffic?
One possible answer could be:
- solicited TCP packets are packets that are part of an existing TCP
connection
- they can just block TCP SYNs from the world to you. All TCP
connections start with a SYN.
Ersek, Laszlo
http://en.wikipedia.org/wiki/Netfilter#Connection_Tracking
This is Linux (the kernel) specific, but demonstrates the general idea.
In the current thread's parlance, "solicited" (inbound traffic) would
correspond to the union of netfilter's ESTABLISHED and RELATED.
lacos
David Schwartz
> As far as I can tell, it's just some guy on
> alt.comp.networking.connectivity using the word "solicited" like this:
> Solicited traffic is traffic that's in response to something you
> initiated on your end, like clicking a web link or logging into your
> email server to send or retrieve email. Unsolicited traffic is not
> in response to a request. The mechanics of how the packets differ
> assumes some detailed knowledge of the 7 layer OSI model and might
> be more than you want to know.
> I must say I have no precise idea what he's talking about, especially
> in that odd reference to the OSI model.
What he means is that you mean need to understand the application to
know whether a particular packet is solicited or not. An application
might contains some application-level request that another machine
with a different IP address initiate a TCP connection to me. That
connection is technically solicited. But you'd have to understand the
application protocol to realize that.
> > The main question is: Where and how do the solicited and unsolicited
> > inbound traffic differ from each other?
> > And also: How do ISP's who block unsolicited inbound traffic on home
> > customers computers ports, distinguish it from solicited inbound
> > traffic?
They don't block "unsolicited inbound traffic" by that definition of
"unsolicited".
> One possible answer could be:
> - solicited TCP packets are packets that are part of an existing TCP
> connection
> - they can just block TCP SYNs from the world to you. All TCP
> connections start with a SYN.
Sure, but that blocks a lot of traffic that may well be requested by
something you did on your end. It's comparable to ISP's that block
"spoofed traffic", but what they mean by "spoofed" is not that the
origin is invalid or incorrect but simply that it's not the one *they*
assigned. Shoot at the wall, towards the target, and call whatever you
can hit the bullseye.
DS
Elton
> something you did on your end. It's comparable to ISP's that block
> "spoofed traffic", but what they mean by "spoofed" is not that the
> origin is invalid or incorrect but simply that it's not the one *they*
> assigned. Shoot at the wall, towards the target, and call whatever you
> can hit the bullseye.
So TCP SYNs can also be the result of a request by me, and a new
connection starts to create as a result of this request.
But then how do ISPs find out if it was a packet sent to me as a
result of a request (solicited packet), or if they are TCP SYN packets
sent to my computer without I requesting it (unsolicited packets) ?
David Schwartz
> So TCP SYNs can also be the result of a request by me, and a new
> connection starts to create as a result of this request.
Correct.
> But then how do ISPs find out if it was a packet sent to me as a
> result of a request (solicited packet), or if they are TCP SYN packets
> sent to my computer without I requesting it (unsolicited packets) ?
They can't. ISP's filter "unsolicited" packets the same way they block
spoofed packets and the same way Texas sharpshooters hit bullseyes.
They define "unsolicited" as "whatever my filters block".
DS
Jorgen Grahn
>> Sure, but that blocks a lot of traffic that may well be requested by
>> something you did on your end. It's comparable to ISP's that block
>> "spoofed traffic", but what they mean by "spoofed" is not that the
>> origin is invalid or incorrect but simply that it's not the one *they*
>> assigned. Shoot at the wall, towards the target, and call whatever you
>> can hit the bullseye.
>
> So TCP SYNs can also be the result of a request by me, and a new
> connection starts to create as a result of this request.
Yes!
> But then how do ISPs find out if it was a packet sent to me as a
> result of a request (solicited packet), or if they are TCP SYN packets
> sent to my computer without I requesting it (unsolicited packets) ?
Well, like Morten writes elsewhere in the thread, they can't. Unless
they get to define the meaning of "solicited" on your behalf.
(By the way, I have never heard of ISPs that do crazy stuff like
that.)
Ersek, Laszlo
I believe my ISP blocks the ports nmbd and smbd would normally bind, so
that domestic subscribers running Windows can't accidentally share their
folders and printers. I also hear that for domestic subscribers, 25/tcp is
blocked, so that they can't run their own SMTP servers. (The reasoning
goes supposedly like "if you want such functionality, buy a business
package".)
lacos
David Schwartz
> I believe my ISP blocks the ports nmbd and smbd would normally bind, so
> that domestic subscribers running Windows can't accidentally share their
> folders and printers. I also hear that for domestic subscribers, 25/tcp is
> blocked, so that they can't run their own SMTP servers. (The reasoning
> goes supposedly like "if you want such functionality, buy a business
> package".)
Right, but they don't pretend that this separates solicited from
unsolicited traffic.
DS