Solicited vs. Unsolicited TCP/IP packets. How do they differ?

[Elton]

Hi!
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]

Post by 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?

"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]

Post by Ersek, Laszlo

Post by 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?

"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

I was asking more about details how does it works from the OSI layers
perspective.

[Jorgen Grahn]

Post by Elton

Post by Ersek, Laszlo

Post by 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?

"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

I was asking more about details how does it works from the OSI layers
perspective.

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

[Elton]

No it's not an error message.
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]

Post by Elton
No it's not an error message.
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.

Post by Elton
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.

/Jorgen

[David Schwartz]

Post by Jorgen Grahn
As far as I can tell, it's just some guy on
  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.

Post by Jorgen Grahn

Post by Elton
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".

Post by Jorgen Grahn
- 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]

Post by David Schwartz
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.
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]

Post by Elton
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.

Post by Elton
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]

Post by Elton

Post by David Schwartz
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!

Post by Elton
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.)

/Jorgen

[Ersek, Laszlo]

Post by Jorgen Grahn

Post by Elton

Post by David Schwartz
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!

Post by Elton
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.)

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]

Post by 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".)

Right, but they don't pretend that this separates solicited from
unsolicited traffic.

DS

[Morten Reistad]

Post by David Schwartz

Post by 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".)

Right, but they don't pretend that this separates solicited from
unsolicited traffic.

ISPs with 1/10th of a clue usually block, or redirect, ports that are
obvious, huge security or spam risks. The nmbd, smbd sockets are such
candidates. So is mail, for spam reasons. These are usually redirected,
not outright blocked. If they have a clue, that is.

But large, dilbertified organisations are taking over. They don't have
a clue at all, they just follow procedures. So, you would need a vpn
to somewhere to actually have incoming queries at all. Fortunatly, you
can get hosted, virtual partitions suitable for such vpns quite cheaply.

One setup that works very well is to have the primary MX be to an
ipv6 only host, and the secondaries to run greylisting. The bots haven't
coded for that yet.

-- mrr

[Morten Reistad]

Post by Elton

Post by Elton
No it's not an error message.

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
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.

This assumes a client-server model. That is not the model for the
Internet. The Internet is a peer to peer network. Many services are
client-server, like the endpoint of most mail, web surfing etc.

When I point an MX to a machine on my LAN I shouldn't be surprised when
mail starts to arrive at that machine. When I point a www.somedomain.com
A and AAAA record there I shoulw expect web queries.

This is not something initiated in my end, protocol-wise. It is
done on a remote server.

Post by Elton
I must say I have no precise idea what he's talking about, especially
in that odd reference to the OSI model.

Post by Elton
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?

- 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.

The short answer is that they cannot, and still deliver internet
service.

-- mrr

[Ersek, Laszlo]

Post by Elton
No it's not an error message.
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?

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