[vox-tech] firewall question

[ME]

On Thu, 3 Jan 2002, Peter Jay Salzman wrote:
> web and ssh work fine just opening up 80/tcp and 22/tcp.   what exactly
> are the udp ports used for?   is there any reason to open them up?

Since others have answered the question specific to these services, I
won't go there much*, but instead try to explain the general case for
other people. (I am guessing that Peter and those that answered already
know the general case described below.)

*(Brief: I was told UDP port 22 was used by an ancient copy of PC
AnyWhere, and some web servers that did audio/video streaming would have
it use UDP port 80 in older copies of RealServer and just not use TCP for
real at all- they over-rode the defaults for port use on the server.)

A tcp packet:
http://mike.passwall.com/networking/tcppacket.html

has enough header information to allow for creation of reliable sessions
http://mike.passwall.com/networking/netmodels/tcpip5layermodel.html

This means that you can be certain that packet's payloadare disassembled
in the same order they were assembled, and the payload of the (tcp)
packets sent are not damaged in transit. Very useful for things like ssh,
telnet and web data. (You don't want characters transposed? OK, then use
TCP or make an application layer thing-a-ma-bob that deals with
errors/corrections (NFS).

A UDP packet:
http://mike.passwall.com/networking/udppacket.html
lacks the header information to deal with reliable sessions. UDP packets
may be received in the wrong order. No attempt is ever guaranteed for
replacement of a bad UDP packet with invalid data with a good UDP packet
with good data. When the UDP packet arrives that has a bad payload/broken,
it can just be dropped and we proceed on with the data lost forever**.

**(Of course this is not always the case)

Both TCP and UDP packets are usually the payload of an IP packet:
http://mike.passwall.com/networking/ippacket.html

Why would you want to use UDP if it is unreliable and packets may come in
in the wrong order?

With TCP, a missed packet in a stream means that all "good packets"
received after the bad packet must wait until the "bad packet" is
retransmitted before the other "good packet's" payload (after the bad one
in sequence) may have their payloads passed onto the application(s) that
asked for them. This is good for telnet (no re-ordering of payload data in
a stream.) However, imagine you are listening to a radio broadcast. If you
receive a bad packet in the middle of a broadcast, you do not want to have
the broadcast STOP while your system waits for the bad data to be
retransmitted. Instead, just a bit of "static" or a gap in the broadcast
may be what you want. (It is especially bad with things like music. You
can bump along with the beat even when there is occasional dead air, but
having the beat stop and then restart is a little uncomfortable.) When you
actually start getting the good data, you hear more of the broadcast.
Interruptions do not cause you to get "behind" but instead allow you to
keep listening and move ahead.

Looking at the UDP packet vs a TCP packet, you can see that a TCP packet
has at least 20 bytes for header data (not counting options and extras)
while the UDP has at least 8 bytes of overhead. The overhead incurred by
the header for TCP (information used to help ensure a reliable connection
mostly) is over 2x that of UDP. However, since UDP does not require a
session (the Whole, SYN, ACK, etc) a host need not use a valid IP address
when manufacturing a UDP packet and sending it on its way. OTOH, a TCP
packet requires some exchange in an initial setup between two machines
"talking" to each other with each one using a sequence number that must be
part of the ACK for the other party's response. Without actually seeing
the returning packet, you would need to guess the number (not as hard on
some systems as you might think). UDP is not considered very secure. NFS
has used UDP for a long while. This helps for effective throughput
(smaller header) at the cost of the application layer doing the
error-control/repair *and* a greater lack of security in having no
guarantee that the packet received was really from the IP address the
packet claims it is from.

If you do not need a UDP service or can choose between TCP vs UDP, TCP can
offer more security.

-ME

(I get paid by word when I post to this group, right? ;-)

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$) P+$>+++ 
L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP
t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z?
------END GEEK CODE BLOCK------
decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html