[unisog] Port 0

Alan Amesbury amesbury at oitsec.umn.edu
Tue Nov 1 00:20:50 GMT 2005


Rudolph Pereira wrote:

> So, given that the only solid report of udp/0 traffic is actually IGMP,
> I'd still, for one, be interested in any other evidence that udp/0 is
> associated with valid traffic.


QUICK ANSWER
------------
I think you're confusing protocols.  IGMP, UDP, and TCP are all IP
protocols.  See /etc/protocols on a reasonably up-to-date Unix box for a
list, or RFC1700 ("Assigned Numbers").  A copy of the latter is
available from

    http://www.faqs.org/rfcs/rfc1700.html


IGMP doesn't appear to have a concept of "ports" like UDP and TCP do. 
Tools reporting any sort of port number are probably flawed in some way,
even if it's only in the way they describe the contents of IGMP packets.

TCP and UDP traffic to or from port zero is very likely due to some
misconfiguration, gross error or bug, or is artificially generated and
likely malicious.  I note that much of the Windoze Messenger spam
(traffic targeting 1025/udp and 1026/udp) is from source port zero,
which I consider conclusive evidence that the people generating it
aren't too bright.





LONG ANSWER (WITH SOME REFERENCES)
----------------------------------
The only routine traffic I've personally seen in large quantities
involving UDP port zero was back in '99 and was due to a bug.  A large,
local ISP had a number of customers with DSL service provided using
Cisco 675 DSL routers.  Many people affiliated with UofMN were customers
of this ISP, and (mistakenly) used UofMN nameservers in their
configurations, instead of using the nameservers belonging to their
ISP.  The Cisco 675 would send DNS queries (after running them through
NAT/PAT) with the source port set to zero.  These queries would get
dropped by the nameserver (a BIND variant) and would cause the
nameserver to generate a log entry ("...dropping source port zero
packet...").  The Cisco 675 would then select an ephemeral port, resend
the packet, and things would work.  I suspect this was a failed socket()
call in the Cisco 675, as most operating systems (but apparently not the
version of CBOS in use on these devices) pick ephemeral ports when a
socket is created with the port set to zero.  This behavior went away
over time as customers upgraded their DSL routers.

RFC1700 ("Assigned Numbers") lists port zero, like protocol zero, as
reserved.  While there may be a newer version of the assigned numbers
RFC, I don't think this part has changed.

RFC768 ("User Datagram Protocol") and RFC793 ("Transmission Control
Protocol") clearly describe UDP and TCP as having port numbers.  RFC792
("Internet Control Message Protocol") clearly describes ICMP *NOT* as
having port numbers, but does describe the ICMP header as having message
types and message codes.  For example, type 3 code 3 is "ICMP port
unreachable".  Even for an ICMP port unreachable message, discussion of
port numbers as they relate to ICMP is irrelevant, as ICMP doesn't
directly report which port is unreachable, but simply includes packet
header information from the packet that caused the port unreachable
message to get generated.

Like ICMP, I don't think it makes sense to discuss port numbers in
conjunction with IGMP, and suspect that tools that report a port number
for IGMP traffic (IP protocol 2) are probably broken in some way (at
least in their method of presentation, if not in some other,
fundamental, and more serious way).  RFC1112 ("Host Extensions for IP
Multicasting") seems to support this suspicion, as the packet structure
described in Appendix I (IGMP v1) doesn't make reference to any sort of
port number.  It may be, however, that the tool is reporting as a "port
number" an IGMP-specific message or code, similar to what I think was
mentioned for ICMP.  Near as I can tell, IGMP isn't supposed to span
administrative boundaries, i.e., it's something that should probably be
blocked at borders.  However, I've no direct experience with IGMP, so my
IGMP kung fu is, in a word, weak.

Links:

    RFC792 - http://www.faqs.org/rfcs/rfc792.html
    RFC793 - http://www.faqs.org/rfcs/rfc793.html
    RFC1112 - http://www.faqs.org/rfcs/rfc1112.html
    RFC1700 - http://www.faqs.org/rfcs/rfc1700.html


Of course, if I screwed up in my citations or interpretations, let me
know!  Halloween weekend was fun, but kinda rough.  :-)


--
Alan Amesbury
University of Minnesota


More information about the unisog mailing list