[pchelpers] Re: UDP Packets

It sure does-- Thank you very much Nigel-- Jackie

-----Original Message-----
From: pchelpers-bounce@xxxxxxxxxxxxx
[mailto:pchelpers-bounce@xxxxxxxxxxxxx] On Behalf Of Nigel
Sent: Monday, September 03, 2001 9:44 PM
To: pchelpers@xxxxxxxxxxxxx
Subject: [pchelpers] Re: UDP Packets


The following is from:
http://www.erg.abdn.ac.uk/users/gorry/course/inet-pages/udp.html

The User Datagram Protocol (UDP) is a transport layer protocol defined
by
the US Department of Defence (DoD) for use with the IP network layer
protocol. It provides a best-effort datagram service to an End System.



The following is from"
http://www.samspade.org/d/faq

Most systems on the internet will see occasional unexpected traffic on
their
public network interfaces. This is nothing to be concerned about.

In particular, UDP packets in the range 33434 to 33523 are normal and
expected. They're a sign of someone using traceroute.

Many 'personal firewall' security programs are faulty, and they will
report
this normal, expected traffic as a security problem. If yours does,
contact
the vendor of your software. Do not contact me.

Similarly many inexperienced system administrators see accesses to a
range
of UDP ports and panic needlessly.

Traceroute is a network diagnostic tool used to map out the path an IP
packet will take from the source system to the destination system.

(If you don't understand TCP/IP much you might want to try the
alternative
explanation of traceroute and section 3.4 of RFC 2151 instead)

There are a few variants, but most traceroute algorithms rely on sending
a
sequence of packets from the source to the destination, each successive
packet having its TTL (time to live) field increased by one.

The first packet sent out will have a TTL of one, and will be killed at
the
first router. That router will return an ICMP TIME_EXCEEDED response to
the
source system. This is repeated until the packet reaches the
destination, or
a limit is reached.

Most unix traceroutes send UDP packets to high (unused) ports, and
recognise
they've reached the destination system when they receive an ICMP
UNREACHABLE
response.

(Most Windows hosted traceroutes use ICMP ECHO_REQUEST packets instead,
and
some unix hosted traceroutes can be configured to use ICMP ECHO_REQUEST,
UDP
packets or even IP tunneling packets. UDP is by far the most common
outside
the Windows world.)

If the destination system is unavailable, or has been misconfigured[1]
to
drop packets then traceroute will not receive that UNREACHABLE response
and
will assume the packets it sent were lost and keep sending until it
reaches
a maximum limit.

By default most traceroutes will send three packets at each TTL, to a
maximum TTL of thirty - a maximum of 90 packets in total.

Traceroute will send a sequence of UDP packets to a range of high
ports[3],
by default it will start at port 33434. Each datagram it sends out will
be
to one port higher, so the typical range of destination ports used will
be
33434 to 33523. All the parameters are user configurable, so ports
outside
that range may occasionally receive datagrams from traceroute.

(An ICMP TIME_EXCEEDED packet has only an eight byte payload, so will
only
contain the header of the expiring UDP packet, not any of the UDP
packets
payload. So to associate replies with the original datagram the
necessary
information must be coded in the UDP header. To allow multiple
traceroutes
simultaneously, the process ID is coded into the UDP source port and
that
leaves the destination port as the only convenient field to store the
packet
count in.)

A destination system should see no more than three UDP port accesses in
that
range, unless it is misconfigured to drop UDP packets in that range
rather
than refusing them. If it is misconfigured in that way then it will see
datagrams dropped at sequential destination ports in that range.


Hope this answers all the questions.
Nigel


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.274 / Virus Database: 144 - Release Date: 8/23/2001

Other related posts: