Private port numbers?
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. -- Crist J. Clark crist.clark@globalstar.com
On woensdag, aug 13, 2003, at 21:38 Europe/Amsterdam, Crist Clark wrote:
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.
On Wed, 13 Aug 2003, Iljitsch van Beijnum wrote:
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.
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, 13 Aug 2003, Crist Clark wrote:
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.
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)
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 -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me.
It's a good idea, granted, but isn't this covered by IPv6 administrative scoping? Lars -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of David G. Andersen Sent: Thursday, August 14, 2003 8:33 AM To: Christopher L. Morrow Cc: Crist Clark; nanog@merit.edu Subject: Re: Private port numbers? 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 -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me.
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. -- Crist J. Clark crist.clark@globalstar.com
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.) -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE I feel ... JUGULAR ...
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. -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster@globalstar.com
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 On Thu, Aug 14, 2003 at 02:49:10PM -0700, Crist Clark wrote:
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. -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387
The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster@globalstar.com
On Wed, 13 Aug 2003, Crist Clark wrote:
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
Can't wait to read the draft and RFC. Rock on.
participants (8)
-
Christopher L. Morrow -
Crist Clark -
David G. Andersen -
Iljitsch van Beijnum -
Jeremy T. Bouse -
Lars Higham -
Mans Nilsson -
Stephen J. Wilcox