Be damned if you filter, be damned if you don't. Nice choice.
I think it's time that we set aside a range of port numbers for private use. That makes all those services that have no business escaping out in the open extremely easy to filter, while at the same time not impacting any legitimate users.
Services could even be assigned two port numbers: a public one and a private one. So I could use port 80 to access the web, but port 32768 + 80 (or whatever) to manage my ADSL modem over HTTP. Applications would just need a few lines of code to try either the public or the private port first (depending on the type of application and possibly some heuristics) and try the other port when there is a destination port unreachable or administratively prohibited message.
(Note that what I mean here has nothing to do with what IANA calls "private" ports.)
Iljitsch van Beijnum wrote:
Be damned if you filter, be damned if you don't. Nice choice.
I think it's time that we set aside a range of port numbers for private
use. That makes all those services that have no business escaping out
in the open extremely easy to filter, while at the same time not
impacting any legitimate users.
Cool. So if you use private ports, you'll be totally protected from the
Internet nasties (and the Internet protected from your broken or malicious
traffic) in the same way RFC1918 addressing does the exact same thing now
at the network layer.
I'm sure everyone will filter private ports just as effectively as RFC1918
and martian addresses are filtered at borders now.
Can't wait to read the draft and RFC. Rock on.
Cool. So if you use private ports, you'll be totally protected from the
Internet nasties (and the Internet protected from your broken or malicious
traffic) in the same way RFC1918 addressing does the exact same thing now
at the network layer.
That would be the theory, yes. (I grant you that it won't be quite this simple in practice.)
I'm sure everyone will filter private ports just as effectively as RFC1918
and martian addresses are filtered at borders now.
It's not the same thing. RFC 1918 and martian addresses aren't supposed to be present on the internet, but aren't automatically harmful. Having services that are explicitly labeled for internal use be visible to the rest of the world is potentially very harmful.
what about ports that start as 'private' and are eventually ubiquitously
used on a public network? (Sean Donelan noted that 137->139 were
originally intended to be used in private networks... and they became
'public' over time)
I think I'm missing something, how would a locally managed firewall (local
to the end station) not permit this same scenario? (without the added
confusion of private/public ports)
On Wed, Aug 13, 2003 at 10:40:30PM +0000, Christopher L. Morrow quacked:
what about ports that start as 'private' and are eventually ubiquitously
used on a public network? (Sean Donelan noted that 137->139 were
originally intended to be used in private networks... and they became
'public' over time)
You run it on a different port. I actually really like this idea,
because it makes shipping a more secure default configuration
easier for vendors without having to coordinate between firewall
vendors and implementors.
The "gotcha" is that it makes life pretty weird for you if you
then want to make your service work in the wide-area... but
that's pretty easy to do with intelligent defaults:
Ports 1-1024: Well-known-ports
Ports 60001-61024: Private well-known-port analogues
Applications would try:
if (!connect(..., public port #))
connect(..., private port #))
In fact, this (impractically) generalizes to a nice way of
signifying whether or not you want external people to be
able to talk to your service:
port bit[0] == 0: Public service, please do not filter
port bit[0] == 1: Private service, please filter at
organizational boundary
I suddenly wish the port space was 32 bits. 
People _could_, of course, implement all of this with
tcpwrappers and host-local firewalls. But experience has
shown that they don't. It might be easier for them if they
could just click "private" when they configured the service,
though experience has shown that services migrate to the less
restrictive mode as debugging and time goes on...
-Dave
It's a good idea, granted, but isn't this covered by IPv6 administrative
scoping?
Lars
Iljitsch van Beijnum wrote:
>
> Be damned if you filter, be damned if you don't. Nice choice.
>
> I think it's time that we set aside a range of port numbers for private
> use. That makes all those services that have no business escaping out
> in the open extremely easy to filter, while at the same time not
> impacting any legitimate users.
Cool. So if you use private ports, you'll be totally protected from the
Internet nasties (and the Internet protected from your broken or malicious
traffic) in the same way RFC1918 addressing does the exact same thing now
at the network layer.
Erm? Unless your nasty uses TCP (requiring two-way) you still get the same
potential to spread worms etc as you do on 1918 currently
I'm sure everyone will filter private ports just as effectively as RFC1918
and martian addresses are filtered at borders now.
Whoa people filter these things, news to me!
Steve
Lars Higham wrote:
It's a good idea, granted, but isn't this covered by IPv6 administrative
scoping?
That's the network layer, not the transport layer. IPv6 scoping has the
potential to be very helpful for private addressing since it's fundamentally
built into the protocol, as opposed to RFC1918 addresses which are just
kinda an afterthought. This means that, by default, vendor products should
DTRT with respect to scoped addresses, and administrators have more
effective tools.
However, giving administrators more tools is not always a good thing. I
fully expect to see the clueless, the same people who don't filter
RFC1918 spoofs at their border now, open up their border routers to let in
privately scoped addresses from the outside world. And I expect there will
be ISPs that let privately scoped addresses pass over their networks 'cause
some clueless customers, with $$$ contracts, want to pass the traffic between
different sites. And some vendors will ship with bad defaults and bugs.
So, I expect private networks with global connectivity (kind of an oxymoron,
but you know what I mean) will be easier to set up and set up more securely
with IPv6. But it's no magic bullet. There will be some brilliant fools out
there who manage to shoot themselves in the foot. That problem will never
go away. Unfortunately, besides shooting themselves, these people cause
some collateral damage too (just like this worm that started the discussion).
We'll have to wait until IPv6 is widely deployed to really see how all of
that works out.
Lars Higham wrote:
>
> It's a good idea, granted, but isn't this covered by IPv6 administrative
> scoping?
That's the network layer, not the transport layer. IPv6 scoping has the
potential to be very helpful for private addressing since it's fundamentally
built into the protocol, as opposed to RFC1918 addresses which are just
kinda an afterthought. This means that, by default, vendor products should
DTRT with respect to scoped addresses, and administrators have more
effective tools.
Unless I am out hiking completely, you are talking about site-locals.
Please don't: They are no more -- the ipv6 session at the SF IETF
reached in-room consensus about removing them, a decision that was
later confirmed on the mailing list. There are people who did not
like this, and they rather loudly try to get the decision reversed,
but they are the minority.
Site-locals are, thank $DEITY, a thing of the past.
(OTOH, Link-locals still remain in the protocol.)
Mans Nilsson wrote:
Subject: Re: Private port numbers? Date: Thu, Aug 14, 2003 at 11:41:25AM -0700 Quoting Crist Clark (crist.clark@globalstar.com):
>
> Lars Higham wrote:
> >
> > It's a good idea, granted, but isn't this covered by IPv6 administrative
> > scoping?
>
> That's the network layer, not the transport layer. IPv6 scoping has the
> potential to be very helpful for private addressing since it's fundamentally
> built into the protocol, as opposed to RFC1918 addresses which are just
> kinda an afterthought. This means that, by default, vendor products should
> DTRT with respect to scoped addresses, and administrators have more
> effective tools.
Unless I am out hiking completely, you are talking about site-locals.
Please don't: They are no more -- the ipv6 session at the SF IETF
reached in-room consensus about removing them, a decision that was
later confirmed on the mailing list. There are people who did not
like this, and they rather loudly try to get the decision reversed,
but they are the minority.
Site-locals are, thank $DEITY, a thing of the past.
(OTOH, Link-locals still remain in the protocol.)
Without trying to find the mailing lists for the IPv6 working groups,
this must have been pretty recent. I just check up on RFCs every once
in a while and RFC 3513, dated April 2003, still talks about Site-Local.
RFC 3587, from this month, talks about losing Top Level Aggregators
and Next Level Aggregators, but that's something different.
I don't doubt you though, even though it's being deployed, IPv6 is far
from completely specified. The details still move around faster than
I'll be followoing. Heck, no one really has found a good way to use the
DIFSERV fields of IPv4 yet.
The IETF IPNG WG home page can be found at:
http://playground.sun.com/ipng
The decision regarding site-local was made during the San
Francisco IETF meeting and then later confirmed on the mailing lists
although there has been quite some debate over it all since then. IIRC
the SF IETF meeting was in April which would have been before 3513. The
WG is still trying to nail everything down as there are a number of
I-D's out but still some are calling for SL to be included to some
degree thus none have been able to work their way to becoming an RFC.
If you have nothing to do for a couple days reading through the
hundreds of posts regarding SL can definately kill the time...
Regards,
Jeremy