Subject: RE: [tcpm] security draft input request

From: "Christian Huitema" <[email-masked]>
Date: Mon, 3 May 2004 09:25:59 -0700

> I have a question about random ports... I have been
> told that some ACL/Firewalls will block out ranges of ports
> for peers to get through on (this seems a bit hard from me
> to accept so I have sent a email to the source of the news
> asking for clearification)... if this is true then  randomization
> of ports would be interfered with by middle boxes as well... sigh..

Firewalls do indeed block random port numbers, as well as random
combinations of TCP flags. However, firewalls typically classify
connections as incoming or outgoing, and will typically only examine the
"server" port, i.e. the destination port in the first SYN packet. For
example, a web connection is typically established to port 80 from a
random source port, and firewalls don't block that. 

In the case of BGP, instead of starting a connection from port 179 to
port 179, routers could presumably start a connection from a random port
to port 179. It would take a very stubborn firewall to allow a
connection to 179 from 179, and block a connection from random to 179. 

There are two ways of obtaining this randomization of the source port.
Using the socket API, the simplest way is to simply leave the source
port number unspecified, and rely on the OS to implement randomization.
The more complex way is to draw a random port number in the application
and bind to that port number before issuing the socket call; the
programmer will have to manage collisions if the port happens to be
already in use.

The firewall issue does limit what the OS can do. This is not so much an
issue with BGP as it is with some applications that do not use fixed
port numbers for either the servers or the clients; instead, the clients
rely on a name service (RPCDSS for RPC and DCOM in Windows) or a
signaling service (SIP or H.323) to learn both the address and the
listening port of the server. Some firewalls attempt to accommodate
these applications by guessing the range of ports that the applications
will use, and then opening that range. This creates an "application
compatibility" issue: if we change the way in which the OS allocates
port numbers, we risk picking ports that these firewalls don't expect.
Users will see an RPC or H.323 application suddenly fail after an OS
upgrade, and they will question the sanity of the upgrade.

But the firewall compatibility issue does not occur when the server side
of the application uses a fixed port, such as 179. Firewalls can be
reliably programmed to allow or disallow BGP, or any fixed port
application. For these applications, and specially for critical
applications like BGP, it makes a lot of sense to explicitly bind to a
random port number before issuing a connect call. (Add mandatory
reference to RFC 1750 for the choice of random numbers.) You will get a
solution that is robust, regardless of the level of port randomization
or TCP protection implemented in the platform.

-- Christian Huitema

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 03 May 2004 14:42:25 -0400

Christian:

I am aware of the methods to get randomized ports... and
it seemed kinda funny to me....

Here is a quote from the response email I got from one
of my colleages...

"
Yes, it's true, and yes, it's a huge problem. RTP can be anywhere in
the range 16384 to 32768. We have ALGs to open single ports
dynamically, but they break when the voice signaling is encrypted as
we're now doing in CCM 4.0. As an alternate, we can let those ports
initiate a connection through the firewall (or used the "established"
param in an ACL) as long as it originates on a more trusted interface.
That works as long as all of the devices on the more trusted interface
will begin streaming media as soon as the connection is open. Virtually
everything will do that with the possible exception of conference
bridges and transcoders.

But it's not just RTP we're worried about, and unfortunately, we're weak
on the details. That's why I'm working on it right now. But for
instance, IPMA uses a random port somewhere in the 5000-6000 range.
There's no ALG for that. H.323 can use a myriad of ports. Fortunately,
we usually don't have to let them out to the end user community.

I know there's more, but I can't tell you what they are right now. Give
me a couple of weeks and I should know a whole lot more. But it scares
me when something new comes along and suggests we use random ports.

"

So it would appear that true random ports will cause some apps
pain too... sigh.. it appears that middle boxes do further and further
nasty things... or maybe its like fire arms.. its not the weapons
themselves but the people who use them that cause the problems :-0

When I get further details I will forward them on to the list.

R

-- 
Randall R. Stewart
ITD - Transport Technologies
815-477-2127(o) or 815-342-5222(c)

---

From: Andras Salamon <[email-masked]>
Date: Tue, 4 May 2004 17:01:13 +0200

> connection to 179 from 179, and block a connection from random to 179. 

Unfortunately, we saw something similar when the default zone transfer
settings for the BIND DNS name server changed.  For many years, BIND
used source port 53 when initiating TCP zone transfers (the destination
port for these is of course 53), and some years ago the default changed
to use a random source port.  It took several years for the BIND port
randomization to penetrate the firewall community and for middleware
boxes to stop blocking zone transfer attempts from newer BIND servers.

A lot of firewall implementors seem to believe that attackers are unable
to spoof source ports.  It would be nice if firewall implementors
understood that specifying any source port is trivial, that script
kiddie attack kits already do this, and that firewall rule sets therefore
should not rely on source port numbers to classify goodness or badness
of packets.

However, we need to start nudging the process even if it is going to take
several years to filter into the less enlightened parts of the net, so I
still suggest the BGP people (Pekka et al?) be encouraged to explicitly
mention that random source ports are allowed.  This is fine according to
the BGP standards, but for some reason everyone seems to have derived
firewall rule sets from the existing implementations instead of the
standards -- just like with DNS.  If we agree with the existing usage,
then we should formalise the de facto usage in the standards process.
If we disagree, then we should tell the middleware people to conform to
the standards.  Since when does middleware dictate protocol standards,
anyway -- what happened to the end-to-end argument?

-- Andras Salamon                   [email-masked]