Re: Guidance needed on well known ports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, all, In response to some discussion on this mailing list, the following ID has been submitted. It's intended to become a TCPM work item (thus the header) if there's sufficient interest. PLEASE TAKE FURTHER DISCUSSION TO THAT LIST ([EMAIL PROTECTED]) For the original discussion, see the ietf@ietf.org archives, and look for Guidance needed on well known ports. The draft available at the following URL until it's in the ID repositories: http://www.isi.edu/touch/pubs/draft-touch-tcp-portnames-00.txt Joe - TCPM WGJ. Touch Internet Draft USC/ISI Expires: October 2006April 14, 2006 A TCP Option for Port Names draft-touch-tcp-portnames-00.txt ... Abstract This document specifies a new TCP option that specifies services by a string name. This option separates the use of port numbers for connection demultiplexing from their use as a service identifier. The option allows a larger number of concurrent connections for a particular service, as well as potentially enabling more explicitly coordination of services behind NATs and firewalls. This option should be supported in new TCP implementations. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEQCY0E5f5cImnZrsRAsCqAKDOYDDorIRcA04GDZBTtWX2NUfHKQCfbfi3 qVbx2jZQAcPDyeo+5/2x35Y= =wJb2 -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Hi, Noel (et al.), Noel Chiappa wrote: From: Joe Touch [EMAIL PROTECTED] TCPMUX doesn't 'handoff'. It expects that .. the service desired is served off of its port once opened after the initial exchange (in-band). .. The downside is that it then forces a two-step demultiplexing of incoming packets; there may be utility in a variant that allows the dest port to be unbound and later filled-in, or changed during the connection, so that services can be more efficiently demultiplexed. I'm missing something here. A TCP connection is identified by the (srcaddr, sport, dstaddr, dport) tuple. TCB's are looked up by this tuple. Connections to TCPMUX will all have the same dstaddr/dport, but will presumably have different srcaddr's, and (presumably) random sport's, and can be distinguished that way. Why can't the TCPMUX listener just bind the correct application to the TCB (after figuring out what the appropriate application is), and then forget about the connection, leaving it entirely to the application to deal with? There are three ways to proceed: 1) set the port number after the handshake (as I described) i.e., dynamic port negotiation 2) continue to use the initial port number for packet demuxing i.e., portname demuxing 3) let the port number be fixed, but use the string for the service binding #3 solves the problem of service binding without involving the DNS, allowing endpoints to determine the meaning of a port (which is where that meaning is defined anyway) That's fine, and as others have noted, simpler to implement. The option would be used only in the SYN, and after that it would be unnecessary (and ignored if used). #2 is more complicated, and increases the port space. That's probably unnecessary at this time. #1 is more complicated; it's useful where a number of hosts emulate a single host (e.g., behind a NAT) since it can avoid collisions in selecting the otherwise arbitrary destination port, but again it's unnecessary at this time. So far it looks like only #3 (service binding) will be covered unless there's a real need for either dynamic port negotiation or portname demuxing. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Eliot Lear wrote: In thinking about this some more if we end up with a TCPMUX like approach for TCP, how shall UDP, SCTP, et al be handled? Is it okay to handle them differently? I'm addressing this in the draft (in progress). UDP can't support the idea; there's no option space.The alternative would be to reserve a port and assume that bytes after the UDP header always have the portname, but that seems like a bad idea (interferes with the separation of header and data supported by DMA, e.g.) SCTP and DCCP probably can handle a similar option, but that would be addressed in separate documents. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
In thinking about this some more if we end up with a TCPMUX like approach for TCP, how shall UDP, SCTP, et al be handled? Is it okay to handle them differently? Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
On Friday, March 24, 2006 08:23:20 AM -0500 Steven M. Bellovin [EMAIL PROTECTED] wrote: On Thu, 23 Mar 2006 20:56:51 -0800, Joe Touch [EMAIL PROTECTED] wrote: Since it seems like this might be useful, I'll pull a draft together on how to do this without 1078's extra connection, more like the late-binding we do in datarouter, very shortly... 1078 doesn't use an extra connection; it hands off the open connection to the protocol handler. Your suggestion of using a TCP option instead is friendlier to firewalls, though. And it uses fewer round trips. I like this idea. does require a mod to TCP to allow the dest port to be unbound (e.g., '0') if the option is present, and enable the return SYN-ACK to update the TCB on arrival. This part, though, seems like it could be perilous. Why not start with a non-zero port and hand off the connection, a la tcpmux? -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
On Thursday, March 23, 2006 09:40:06 PM -0800 Stuart Cheshire [EMAIL PROTECTED] wrote: Right now there are a couple of hundred application-layer protocols implemented that work this way. And wow is there a lot of MDNS broadcast traffic on my network. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Jeffrey Hutzelman wrote: On Friday, March 24, 2006 08:23:20 AM -0500 Steven M. Bellovin [EMAIL PROTECTED] wrote: On Thu, 23 Mar 2006 20:56:51 -0800, Joe Touch [EMAIL PROTECTED] wrote: Since it seems like this might be useful, I'll pull a draft together on how to do this without 1078's extra connection, more like the late-binding we do in datarouter, very shortly... 1078 doesn't use an extra connection; it hands off the open connection to the protocol handler. Your suggestion of using a TCP option instead is friendlier to firewalls, though. And it uses fewer round trips. I like this idea. does require a mod to TCP to allow the dest port to be unbound (e.g., '0') if the option is present, and enable the return SYN-ACK to update the TCB on arrival. This part, though, seems like it could be perilous. Why not start with a non-zero port and hand off the connection, a la tcpmux? TCPMUX doesn't 'handoff'. It expects that either the connection is closed and another is opened, or that the service desired is served off of its port once opened after the initial exchange (in-band). The latter is a possibility here. The downside is that it then forces a two-step demultiplexing of incoming packets; there may be utility in a variant that allows the dest port to be unbound and later filled-in, or changed during the connection, so that services can be more efficiently demultiplexed. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
From: Joe Touch [EMAIL PROTECTED] TCPMUX doesn't 'handoff'. It expects that .. the service desired is served off of its port once opened after the initial exchange (in-band). .. The downside is that it then forces a two-step demultiplexing of incoming packets; there may be utility in a variant that allows the dest port to be unbound and later filled-in, or changed during the connection, so that services can be more efficiently demultiplexed. I'm missing something here. A TCP connection is identified by the (srcaddr, sport, dstaddr, dport) tuple. TCB's are looked up by this tuple. Connections to TCPMUX will all have the same dstaddr/dport, but will presumably have different srcaddr's, and (presumably) random sport's, and can be distinguished that way. Why can't the TCPMUX listener just bind the correct application to the TCB (after figuring out what the appropriate application is), and then forget about the connection, leaving it entirely to the application to deal with? All packets which belong to that connection will automatically go to that TCB, and thence to the application, with no second layer of demux needed. Am I missing something? Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
On Apr 6, 2006, at 6:37 PM, Noel Chiappa wrote: Why can't the TCPMUX listener just bind the correct application to the TCB (after figuring out what the appropriate application is), and then forget about the connection, leaving it entirely to the application to deal with? All packets which belong to that connection will automatically go to that TCB, and thence to the application, with no second layer of demux needed. Am I missing something? On BSD and Solaris you can just pass the file descriptor from the new connection to the already running server. --lyndon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
On Thu, 6 Apr 2006 21:37:49 -0400 (EDT), [EMAIL PROTECTED] (Noel Chiappa) wrote: From: Joe Touch [EMAIL PROTECTED] TCPMUX doesn't 'handoff'. It expects that .. the service desired is served off of its port once opened after the initial exchange (in-band). .. The downside is that it then forces a two-step demultiplexing of incoming packets; there may be utility in a variant that allows the dest port to be unbound and later filled-in, or changed during the connection, so that services can be more efficiently demultiplexed. I'm missing something here. A TCP connection is identified by the (srcaddr, sport, dstaddr, dport) tuple. TCB's are looked up by this tuple. Connections to TCPMUX will all have the same dstaddr/dport, but will presumably have different srcaddr's, and (presumably) random sport's, and can be distinguished that way. Why can't the TCPMUX listener just bind the correct application to the TCB (after figuring out what the appropriate application is), and then forget about the connection, leaving it entirely to the application to deal with? All packets which belong to that connection will automatically go to that TCB, and thence to the application, with no second layer of demux needed. Am I missing something? No -- that's precisely how it works. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
From: Joe Touch [EMAIL PROTECTED] Noel Chiappa wrote: From: Keith Moore moore@cs.utk.edu Regarding SRV, it's not acceptable to expect that as a condition of deploying a new application, every user who wishes to run that application be able to write to a DNS zone. Most users do not have DNS zones that they can write to. Yes. Architecturally speaking, it's somewhat dubious that information which really only needs to be localized to the host (application-port binding) has to be sent to the DNS. It would be easy to run a tiny little U[D]P binding server that took in an application name (yes, we'd have to register those, but string-space is infinite), and returned the port. Only if it asked a well-known server ON THAT MACHINE. Yes, but why is that a problem? Again, in architectural terms, you are limiting the scope over which the information (about which appplication is on which port) has to be spread, to the machine it applies to - always good when you get that kind of congruence. Why would you want machine X to know the mapping for machine Y? If you're going to be talking to machine Y anyway (to talk to the application), why can't Y also be the one you ask for the mapping? And then you don't have to set up all the mechanism for machine X to learn what machine Y's mappings are. But we cannot assume a hosts' DNS is available for that purpose. For most of us, the DNS entry isn't under our control, nor is it likely to be for the forseeable future. Keith and I concurred on that. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Ack on Noel's other points, but this is worth mentioning... But we cannot assume a hosts' DNS is available for that purpose. For most of us, the DNS entry isn't under our control, nor is it likely to be for the forseeable future. Keith and I concurred on that. Noel I have learned not to tell people (especially Keith and Noel) that DNS is the right answer to all questions, but it is significantly difficult having most of the machines on the net impossible to locate from most of the other machines on the net. We have solved this problem in the past with a heavy reliance on client-server protocols and SIPpish proxies, which are possible to locate from most of the other machines on the net. I appreciate very much EKR's talk on distributed hash tables at the plenary last night. I don't know if this is the right direction, but the problems DHTs are intended to solve would be useful to solve. And it would be good if we worked on DHTs AND other possible solutions, instead of arguing about whether DHTs are the right answer and not working on anything else, either! Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
From: Spencer Dawkins [EMAIL PROTECTED] I have learned not to tell people (especially Keith and Noel) Hey, I'm nowhere near as hypergolic on this as Keith is... :-) that DNS is the right answer to all questions, Well, it works fine for what it was designed to do. Problem is, people get into this hammer-nail mode, and they have a problem to solve, and not enough (protocol) tools to do it with... (ARP used to suffer the same problem.) it is significantly difficult having most of the machines on the net impossible to locate from most of the other machines on the net. That's more because of NAT, than anything else. Even if you had the IP address, in most cases it wouldn't do you any good. (But now we are drifting off-topic, let's not turn this into the usual NAT rant - or Keith will *really* get going! :-) Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Noel Chiappa wrote: From: Joe Touch [EMAIL PROTECTED] Noel Chiappa wrote: From: Keith Moore moore@cs.utk.edu ... It would be easy to run a tiny little U[D]P binding server that took in an application name (yes, we'd have to register those, but string-space is infinite), and returned the port. Only if it asked a well-known server ON THAT MACHINE. Yes, but why is that a problem? Again, in architectural terms, you are limiting the scope over which the information (about which appplication is on which port) has to be spread, to the machine it applies to - always good when you get that kind of congruence. It isn't a problem, but it isn't DNS if you do it that way - that was my only observation. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Noel Chiappa wrote: From: Keith Moore moore@cs.utk.edu Regarding SRV, it's not acceptable to expect that as a condition of deploying a new application, every user who wishes to run that application be able to write to a DNS zone. Most users do not have DNS zones that they can write to. Yes. Architecturally speaking, it's somewhat dubious that information which really only needs to be localized to the host (application-port binding) has to be sent to the DNS. It would be easy to run a tiny little USP binding server that took in an application name (yes, we'd have to register those, but string-space is infinite), and returned the port. Only if it asked a well-known server ON THAT MACHINE. I.e., pick a port, reserve it for resolution (e.g., like the RPC portmapper works). But we cannot assume a hosts' DNS is available for that purpose. For most of us, the DNS entry isn't under our control, nor is it likely to be for the forseeable future. About the only reason I can see that that would not be desirable would be to avoid an extra RTT to the do that binding lookup. (DNS/SRV solutions might avoid this RTT too, but in that case that benefit doesn't outweigh the costs.) The obvious way to do it, which is have the ICP use the strings directly (as the CHAOS protocols did) is not really feasible now - it would require a change to TCP. That could be done using a late-binding trick like we used for string-based source routing (www.isi.edu/datarouter); we could have a TCP option where the service name occurs (as below), and send it at first to the 'portmapper' port, which would demux it and return it. That does require a mod to TCP to allow the dest port to be unbound (e.g., '0') if the option is present, and enable the return SYN-ACK to update the TCB on arrival. Joe Another option, now that I think about it, though, is a TCP option which contained the service name - one well-known port would be the demux port, and which actual application you connected to would depend on the value in the TCP option. Furthermore it's increasingly necessary that applications be able to work in environments that do not use DNS - such as ad hoc networks or networks that become isolated. Also a good point. Probably the worst problem with destination port numbers is that there aren't enough of them. That's probably something that needs to be addressed in TCP and UDP No, 65K is probably enough (because, recall that a single port can have connections to hundreds of thosands of foreign ports) *provided* that we don't have to assign a well-known port to each application. It's the concept of well-known ports that's broken, not the provision for 65K ports. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Steven M. Bellovin wrote: On Mon, 20 Mar 2006 12:47:46 -0500 (EST), [EMAIL PROTECTED] (Noel Chiappa) wrote: Another option, now that I think about it, though, is a TCP option which contained the service name - one well-known port would be the demux port, and which actual application you connected to would depend on the value in the TCP option. Like tcpmux, port 1, RFC 1078? Exactly, except to use a TCP option rather than putting the port name in the data stream - where it isn't available until the data is already being exchanged (and ack'd). Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Noel Chiappa wrote: From: Steven M. Bellovin [EMAIL PROTECTED] Another option, now that I think about it, though, is a TCP option which contained the service name - one well-known port would be the demux port, and which actual application you connected to would depend on the value in the TCP option. Like tcpmux, port 1, RFC 1078? You know, as I was typing that, I was thinking I'll bet someone has something that does this, and I just don't know about it, and I'm going to look dumb as toast... Sigh... :-) Which leaves us the obvious question: why aren't more people using TCPMux, if it already exists? Because it relies on data and reply is passed in-band. It means that the application ends up thinking the connection is established even if it would have failed. Putting the info in an option is a better solution, since the SYN-ACK can depend on whether the port resolution was successful. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
PS... Joe Touch wrote: Noel Chiappa wrote: From: Keith Moore moore@cs.utk.edu Regarding SRV, it's not acceptable to expect that as a condition of deploying a new application, every user who wishes to run that application be able to write to a DNS zone. Most users do not have DNS zones that they can write to. Yes. Architecturally speaking, it's somewhat dubious that information which really only needs to be localized to the host (application-port binding) has to be sent to the DNS. It would be easy to run a tiny little USP binding server that took in an application name (yes, we'd have to register those, but string-space is infinite), and returned the port. Only if it asked a well-known server ON THAT MACHINE. I.e., pick a port, reserve it for resolution (e.g., like the RPC portmapper works). But we cannot assume a hosts' DNS is available for that purpose. For most of us, the DNS entry isn't under our control, nor is it likely to be for the forseeable future. About the only reason I can see that that would not be desirable would be to avoid an extra RTT to the do that binding lookup. (DNS/SRV solutions might avoid this RTT too, but in that case that benefit doesn't outweigh the costs.) The obvious way to do it, which is have the ICP use the strings directly (as the CHAOS protocols did) is not really feasible now - it would require a change to TCP. That could be done using a late-binding trick like we used for string-based source routing (www.isi.edu/datarouter); we could have a TCP option where the service name occurs (as below), and send it at first to the 'portmapper' port, which would demux it and return it. That does require a mod to TCP to allow the dest port to be unbound (e.g., '0') if the option is present, and enable the return SYN-ACK to update the TCB on arrival. Since it seems like this might be useful, I'll pull a draft together on how to do this without 1078's extra connection, more like the late-binding we do in datarouter, very shortly... Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Noel Chiappa [EMAIL PROTECTED] wrote: Yes. Architecturally speaking, it's somewhat dubious that information which really only needs to be localized to the host (application-port binding) has to be sent to the DNS. It would be easy to run a tiny little USP binding server that took in an application name (yes, we'd have to register those, but string-space is infinite), and returned the port. You may be interested to know that this is the direction we took with Multicast DNS and DNS-based Service Discovery (what Apple calls Bonjour). Every machine runs a little process called 'mdnsd' that answers peer-to-peer SRV queries. The registry of application names (i.e. protocol names) is currently maintained at: http://www.dns-sd.org/ServiceTypes.html Right now there are a couple of hundred application-layer protocols implemented that work this way. They bind to zero, get a random port assigned by the OS, and then register that port with the local 'mdnsd' service. The 'mdnsd' service also offers a workaround for the limitations of NAT. If you have a NAT gateway that speaks NAT-PMP (or the UPnP equivalent), then when the application registers its port with the local 'mdnsd' service, mdnsd talks to the NAT gateway, gets a public-to-private inbound port mapping created, and then mdnsd writes an SRV record into your DNS server (requires permission to update a DNS subdomain where Secure DNS Update is enabled) giving the *PUBLIC* IP address and port for your service. The result of this is that when you turn on Personal File Sharing on your Mac at home behind a NAT gateway, then if you want to, you can advertise that service globally. The port number won't be the usual well-known port for Apple Personal File Sharing, but as long as the client looks up the service via SRV record, it will find the correct port to connect to. Details are given at: http://www.dns-sd.org/ClientSetup.html Stuart Cheshire [EMAIL PROTECTED] * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Stephane Bortzmeyer writes: On Sun, Mar 19, 2006 at 12:42:17PM -0800, Ned Freed [EMAIL PROTECTED] wrote a message of 35 lines which said: The privileged port concept has some marginal utility on multiuser systems where you don't Joe-random-user to grab some port for a well known service. had, not has. The concept was invented at a time where multi-users machines were rare and expensive monsters. So, a request coming from source port 513 probably was serious. Today, any highschool student is root on his PC and therefore this protection is almost useless. Stephane, you are thinking of a different security mechanism based on ports 1024 - the one used by the infamous Berkeley r* utilities to decide whether to trust a client's credentials. This mechanism doesn't use well-known ports, but ephemeral ports 1024 on the client side. I think it is fairly much consensus that this kind of mechanism has become useless years ago, for the reason you state. What we are collecting input on is for which kinds of use (if any) a privileged/well-known (as opposed to just IANA registered) *server* port makes sense. -- Simon. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Simon Leinen wrote: Stephane Bortzmeyer writes: On Sun, Mar 19, 2006 at 12:42:17PM -0800, Ned Freed [EMAIL PROTECTED] wrote a message of 35 lines which said: The privileged port concept has some marginal utility on multiuser systems where you don't Joe-random-user to grab some port for a well known service. had, not has. The concept was invented at a time where multi-users machines were rare and expensive monsters. So, a request coming from source port 513 probably was serious. Today, any highschool student is root on his PC and therefore this protection is almost useless. It never was a protection against malevolent students but it still is a protection against silly mistakes. Just try accidently 'cd / ; rm -R *' You know what I mean with silly mistakes. It makes a difference beeing root or beeing user joe when you accidently execute the shown command. Mistakes like that do happen. Stephane, you are thinking of a different security mechanism based on ports 1024 - the one used by the infamous Berkeley r* utilities to decide whether to trust a client's credentials. This mechanism doesn't use well-known ports, but ephemeral ports 1024 on the client side. I think it is fairly much consensus that this kind of mechanism has become useless years ago, for the reason you state. Behind closed doors and on virtual machines they still work remarkebly well. It would be overkill to run an sshd on each of the virtual machines. So would be logging in as root to directly access the virtual root directories. What we are collecting input on is for which kinds of use (if any) a privileged/well-known (as opposed to just IANA registered) *server* port makes sense. Some 70% of all server machines run operating systems that have a notion of multiuser and of privileged user. Only servers are allowed access to the privileged well-known ports. Allowing non-privileged programmes access to the privileged ports leads to desaster Moving the 1K border for well-known ports up to 16K would be nice in the long run. I agree, on the client only machines the distinction between well-known and not so well-known ports does not make much sense. But those clients cannot live without their servers and the servers would not survive very long without their well-known ports. -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
On Sat, Mar 18, 2006 at 02:09:47PM -0800, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote a message of 163 lines which said: The Internet has a signalling layer, the DNS. Applications should use it. The SRV record provides an infinitely extensible mechanism for advertising ports. I agree here but this means we should keep at least one well-known port, 53. IANA should be told to close the well known ports registry. Applications should use DNS SRV records for service location. I agree with that rule for the *future* protocols. But it does not help with current (and widely deployed) protocols. So, asking IANA to refuse new registrations in the well-known ports registry is one thing, shutting down the registry is another. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
On Sun, Mar 19, 2006 at 12:42:17PM -0800, Ned Freed [EMAIL PROTECTED] wrote a message of 35 lines which said: The privileged port concept has some marginal utility on multiuser systems where you don't Joe-random-user to grab some port for a well known service. had, not has. The concept was invented at a time where multi-users machines were rare and expensive monsters. So, a request coming from source port 513 probably was serious. Today, any highschool student is root on his PC and therefore this protection is almost useless. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Title: Re: Guidance needed on well known ports Refusing new registrations is what I meant by closing the registry. Of course it is not possible to change the way deployed systems work retrospectively. The question was about a new protocol. We are about to see several thousand new web services protocols being developed per year. A port each would be idiotic. Expecting UDDI deployment is at this point futile. The solution that people are going to turn to is to use the existing dns as deployed. Fortunately windows 2k uses srv extensively. We should also promote the use of srv for existing protocols for configuration. _pop3._tcp.example.com can only advertise the location of the pop server. Why not use it and save me debugging mail config for friends and familly? -Original Message- From: Stephane Bortzmeyer [mailto:[EMAIL PROTECTED]] Sent: Mon Mar 20 03:06:23 2006 To: Hallam-Baker, Phillip Cc: ietf@ietf.org Subject: Re: Guidance needed on well known ports On Sat, Mar 18, 2006 at 02:09:47PM -0800, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote a message of 163 lines which said: The Internet has a signalling layer, the DNS. Applications should use it. The SRV record provides an infinitely extensible mechanism for advertising ports. I agree here but this means we should keep at least one well-known port, 53. IANA should be told to close the well known ports registry. Applications should use DNS SRV records for service location. I agree with that rule for the *future* protocols. But it does not help with current (and widely deployed) protocols. So, asking IANA to refuse new registrations in the well-known ports registry is one thing, shutting down the registry is another. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Title: Re: Guidance needed on well known ports Dns is essential already. Firewalls can cope -Original Message- From: Joe Touch [mailto:[EMAIL PROTECTED]] Sent: Sun Mar 19 21:02:42 2006 To: [EMAIL PROTECTED]; ietf@ietf.org; netconf@ops.ietf.org Subject: Re: Guidance needed on well known ports Hallam-Baker, Phillip wrote: From: Joe Touch [mailto:[EMAIL PROTECTED]] And with what port would I reach this magical DNS that would provide the SRV record for the DNS itself? You use fixed ports for the bootstrap process and only for the bootstrap process. Which means that the DNS port needs to be well-known or fixed in advance. Some other issues to be considered: - this change would make the DNS required for proper Internet operation, whereas it is currently optional (i.e., only for finding the IP address).] - hosts may run services but not have control over their own DNS entry (or SRV records) - firewalling based on ports would no longer be useful (one could argue it should not be, but that's a different issue) Fixed ports do not work behind NAT. Anyone who wants to deploy IPv6 would be well advised to pay careful attention to that restriction. SRV ports work just fine behind a NAT. Except that many NATs also intercept DNS requests and redirect them to their own servers, for their own purposes, which can interfere with SRV records (by design). People who do this are rarely trying to break things. They don't *try* to break things, but then tend to. ;-) As to 'by design', they're not so much trying to break as to 'help' (usually for their own purposes). Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Title: Re: Guidance needed on well known ports Two points here. First, I totally agree with Phillip that closing the registry is the right direction to head. It would be lovely if this became a consideration in new protocol work at the IETF. I'm not sure how quickly we can actually close it, but having a chosen and stated direction that points somewhere else seems very appropriate for new protocol work. Please note how long it is taking to kill the classful addressing terminology. If you want to change directions on port number interpretation, please start soon.. Second, as long as the current mechanism is "widely used" (and, with the rise of HTTP-as-transport and port-agile protocols, it's less widely used every day anyway), people try to use the current mechanism to understand and characterize traffic on their networks (you may laugh, and it is getting funnier every day, but they do exactly this with firewall rules, protocol analyzers - and the good ones DON'T use port numbers much any more - and traffic monitors). The definition of an application port is what the two ends of the application think it is. If I think that port 25 is a good port, you do, too, and we never use it for anything else, why is this wrong? It seems to me that saying, "if you want to understand what the traffic on this network looks like, our direction is that you'll need to check SRV records most of the time in the future" seems to give people who do firewalls, traffic monitors, etc. the right signal as well. Thanks, Spencer - Original Message - From: Hallam-Baker, Phillip To: Stephane Bortzmeyer Cc: ietf@ietf.org Sent: Monday, March 20, 2006 6:13 AM Subject: Re: Guidance needed on well known ports Refusing new registrations is what I meant by closing the registry.Of course it is not possible to change the way deployed systems work retrospectively.The question was about a new protocol.We are about to see several thousand new web services protocols being developed per year. A port each would be idiotic. Expecting UDDI deployment is at this point futile.The solution that people are going to turn to is to use the existing dns as deployed. Fortunately windows 2k uses srv extensively.We should also promote the use of srv for existing protocols for configuration. _pop3._tcp.example.com can only advertise the location of the pop server. Why not use it and save me debugging mail config for friends and familly?-Original Message-From: Stephane Bortzmeyer [mailto:[EMAIL PROTECTED]]Sent: Mon Mar 20 03:06:23 2006To: Hallam-Baker, PhillipCc: ietf@ietf.orgSubject: Re: Guidance needed on well known portsOn Sat, Mar 18, 2006 at 02:09:47PM -0800,Hallam-Baker, Phillip [EMAIL PROTECTED] wrotea message of 163 lines which said: The Internet has a signalling layer, the DNS. Applications should use it. The SRV record provides an infinitely extensible mechanism for advertising ports.I agree here but this means we should keep at least one well-knownport, 53. IANA should be told to close the well known ports registry. Applications should use DNS SRV records for service location.I agree with that rule for the *future* protocols. But it does nothelp with current (and widely deployed) protocols. So, asking IANA torefuse new registrations in the well-known ports registry is onething, shutting down the registry is another. ___Ietf mailing listIetf@ietf.orghttps://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
closing the port registry considered harmful (was Re: Guidance needed on well known ports)
Refusing new registrations is what I meant by closing the registry. This would be a disaster. It would mean that application designers would just pick ports at random (some do this already) and there would be no mechanism for preventing conflicts. Regarding SRV, it's not acceptable to expect that as a condition of deploying a new application, every user who wishes to run that application be able to write to a DNS zone. Most users do not have DNS zones that they can write to. Furthermore it's increasingly necessary that applications be able to work in environments that do not use DNS - such as ad hoc networks or networks that become isolated. We should also promote the use of srv for existing protocols for configuration. _pop3._tcp.example.com can only advertise the location of the pop server. Why not use it and save me debugging mail config for friends and familly? Because it will degrade interoperability and cause inconsistent behavior between different mail clients. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Dns is essential already. false. but even to the extent that this is true, this is a bug, not a feature. Firewalls can cope but new applications can't. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Stephane Bortzmeyer wrote: On Sun, Mar 19, 2006 at 12:42:17PM -0800, Ned Freed [EMAIL PROTECTED] wrote a message of 35 lines which said: The privileged port concept has some marginal utility on multiuser systems where you don't Joe-random-user to grab some port for a well known service. had, not has. The concept was invented at a time where multi-users machines were rare and expensive monsters. So, a request coming from source port 513 probably was serious. Today, any highschool student is root on his PC and therefore this protection is almost useless. But does that student have access to the root account on servers which are part of the networking infrastructure? Who cares if Joe User blows up his own config. on a PC that nobody else depends on but Joe? I find the argument flawed -- that because Joe User can be root on his own PC, the concept of privileged access to shared system-critical infrastructure is somehow obsolete. Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
On Mon, 2006-03-20 at 12:09 +0100, Stephane Bortzmeyer wrote: Ned Freed [EMAIL PROTECTED] wrote: The privileged port concept has some marginal utility on multiuser systems where you don't Joe-random-user to grab some port for a well known service. had, not has. The concept was invented at a time where multi-users machines were rare and expensive monsters. So, a request coming from source port 513 probably was serious. Today, any highschool student is root on his PC and therefore this protection is almost useless. you shouldn't allow unrestricted access to the network from unmanaged hosts, that's a recipe for disaster. consider rogue DHCP servers, for instance. we still use host based authentication for port 514 (rsh) on strictly managed networks as a supplement to SSH. this requires physical security for network equipment or exposed hosts (not users) doing 802.1x authentication. the protection is not useless in that environment. -- Kjetil T. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
In general I agree with Phillip but not in this case due to the risks of circular dependencies. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Stephane Bortzmeyer wrote: On Sun, Mar 19, 2006 at 12:42:17PM -0800, Ned Freed [EMAIL PROTECTED] wrote a message of 35 lines which said: The privileged port concept has some marginal utility on multiuser systems where you don't Joe-random-user to grab some port for a well known service. had, not has. The concept was invented at a time where multi-users machines were rare and expensive monsters. So, a request coming from source port 513 probably was serious. Today, any highschool student is root on his PC and therefore this protection is almost useless. But does that student have access to the root account on servers which are part of the networking infrastructure? Who cares if Joe User blows up his own config. on a PC that nobody else depends on but Joe? But if nobody has local access to these servers, why is it is necessary or useful for servers to run with root access in order to bind to these ports? This is why I referred to the utility of this feature as marginal. Its realm of utility is being squeezed on one side by the trend to run critical network services on tightly locked down systems rather than on multiuser machines, and on the other by users who want to run their own stuff doing so on their own machines. I simply don't have enough insight into global usage patterns to agree totally with Staphane's asssrtion that this now has no utility at all. But I think the trends are pretty clear. I find the argument flawed -- that because Joe User can be root on his own PC, the concept of privileged access to shared system-critical infrastructure is somehow obsolete. I don't think anyone is claiming that such access needed to be protected. The issue is rather that the specific mechanism of requiring root can have an amplifying effect on holes in applications, changing them from a threat to the application to a way to attack the entire server the application runs on. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Ned Freed wrote: But does that student have access to the root account on servers which are part of the networking infrastructure? Who cares if Joe User blows up his own config. on a PC that nobody else depends on but Joe? But if nobody has local access to these servers, why is it is necessary or useful for servers to run with root access in order to bind to these ports? I think the discussion has reinforced and crystallized my personal feeling on the subject: - Services will have to start up listening to specific ports. Whether the port number is specified in an RFC, an SRV record or a config file on a dozen other hosts is in fact irrelevant to the fact that they have to start up knowing what port to listen to (unless they have write access to SRV). - The root gets to open ports 1024 mechanism is harmful; there are ports 1024 that need to be opened by non-root processes, and ports 1024 that need to be protected from random programs. - Conclusion 1: Hosts that care about separation of privileges need to be able to specify access rights on ports as part of their configuration - with can be handed out to processes asking for a port being one particular kind of access right. - Conclusion 2: There is no reason for standards to uphold the distinction between 1024 and 1024 any more. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
you shouldn't allow unrestricted access to the network from unmanaged hosts, that's a recipe for disaster. no, what's a disaster is to use source IP addresses or port numbers as an indication of trustworthiness on any network that extends beyond a single room. the notion that you can manage significant numbers of hosts to ensure their trustworthiness is delusional. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Title: Re: Guidance needed on well known ports I concur. On the firewalls issue I see no problem moving from port numbers to a coherent architected alternative. What we should fear is the emergence of numerous ad hoc schemes because nobody proposed an acceptable common architecture. I am disappointed that the response to dkim, marid has been 'don't do too much' and not 'don't drive us into a dead end' We have to work with what we have here, that unfortunately means original dns plus the srv record. -Original Message- From: Spencer Dawkins [mailto:[EMAIL PROTECTED]] Sent: Mon Mar 20 04:38:16 2006 To: ietf@ietf.org Subject: Re: Guidance needed on well known ports Re: Guidance needed on well known portsTwo points here. First, I totally agree with Phillip that closing the registry is the right direction to head. It would be lovely if this became a consideration in new protocol work at the IETF. I'm not sure how quickly we can actually close it, but having a chosen and stated direction that points somewhere else seems very appropriate for new protocol work. Please note how long it is taking to kill the classful addressing terminology. If you want to change directions on port number interpretation, please start soon.. Second, as long as the current mechanism is widely used (and, with the rise of HTTP-as-transport and port-agile protocols, it's less widely used every day anyway), people try to use the current mechanism to understand and characterize traffic on their networks (you may laugh, and it is getting funnier every day, but they do exactly this with firewall rules, protocol analyzers - and the good ones DON'T use port numbers much any more - and traffic monitors). The definition of an application port is what the two ends of the application think it is. If I think that port 25 is a good port, you do, too, and we never use it for anything else, why is this wrong? It seems to me that saying, if you want to understand what the traffic on this network looks like, our direction is that you'll need to check SRV records most of the time in the future seems to give people who do firewalls, traffic monitors, etc. the right signal as well. Thanks, Spencer - Original Message - From: Hallam-Baker, Phillip To: Stephane Bortzmeyer Cc: ietf@ietf.org Sent: Monday, March 20, 2006 6:13 AM Subject: Re: Guidance needed on well known ports Refusing new registrations is what I meant by closing the registry. Of course it is not possible to change the way deployed systems work retrospectively. The question was about a new protocol. We are about to see several thousand new web services protocols being developed per year. A port each would be idiotic. Expecting UDDI deployment is at this point futile. The solution that people are going to turn to is to use the existing dns as deployed. Fortunately windows 2k uses srv extensively. We should also promote the use of srv for existing protocols for configuration. _pop3._tcp.example.com can only advertise the location of the pop server. Why not use it and save me debugging mail config for friends and familly? -Original Message- From: Stephane Bortzmeyer [mailto:[EMAIL PROTECTED]] Sent: Mon Mar 20 03:06:23 2006 To: Hallam-Baker, Phillip Cc: ietf@ietf.org Subject: Re: Guidance needed on well known ports On Sat, Mar 18, 2006 at 02:09:47PM -0800, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote a message of 163 lines which said: The Internet has a signalling layer, the DNS. Applications should use it. The SRV record provides an infinitely extensible mechanism for advertising ports. I agree here but this means we should keep at least one well-known port, 53. IANA should be told to close the well known ports registry. Applications should use DNS SRV records for service location. I agree with that rule for the *future* protocols. But it does not help with current (and widely deployed) protocols. So, asking IANA to refuse new registrations in the well-known ports registry is one thing, shutting down the registry is another. -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Ned Freed wrote: Stephane Bortzmeyer wrote: On Sun, Mar 19, 2006 at 12:42:17PM -0800, Ned Freed [EMAIL PROTECTED] wrote a message of 35 lines which said: The privileged port concept has some marginal utility on multiuser systems where you don't Joe-random-user to grab some port for a well known service. had, not has. The concept was invented at a time where multi-users machines were rare and expensive monsters. So, a request coming from source port 513 probably was serious. Today, any highschool student is root on his PC and therefore this protection is almost useless. But does that student have access to the root account on servers which are part of the networking infrastructure? Who cares if Joe User blows up his own config. on a PC that nobody else depends on but Joe? But if nobody has local access to these servers, why is it is necessary or useful for servers to run with root access in order to bind to these ports? This is why I referred to the utility of this feature as marginal. Its realm of utility is being squeezed on one side by the trend to run critical network services on tightly locked down systems rather than on multiuser machines, and on the other by users who want to run their own stuff doing so on their own machines. I simply don't have enough insight into global usage patterns to agree totally with Staphane's asssrtion that this now has no utility at all. But I think the trends are pretty clear. I find the argument flawed -- that because Joe User can be root on his own PC, the concept of privileged access to shared system-critical infrastructure is somehow obsolete. Joe User is not running critical servers - at least not under windows. And if he really does, he will not do it very long :) That is what my log on echnaton says. Echnaton used to be dsl-router and still is my (local) dns-server, my ftp server, mail-server and ssh-server. Echnaton is automatically running a bunch of things and sending reports. Nothing is done as root, because I am the sysop. ssh, ftp, dns and other nameservices (port 42) all use privileged ports - sometimes not the ports you would guess :) djbdns the part about daemon-tools and tcp can help you out of the user-root crisis. With XEON, VM, CoLinux and others you can run a couple of virtual machines on your one real machine. Running each of your servers on its own virtual hostdoes not cost you much cpu or memory. But running each of your servers in its own virtual machine will protect your real machine from getting hacked. So we still have the privileged ports even if they are distributed over virtual machines. User me still has no reason to bind to a privileged port - and if I do I am shure it is a bug. It does not make sense removing bug protection only because some unfamous collection of bugs cannot be fixed. Believe me it is a dynamically changeing collection of bugs only. It has no operating system structure built in. There is nothing you can relibly run a server on. I tried to. It does not make sense to bend rules breaking systems that do work as servers. Windows is not a player in the server business. Regards Peter and Karin Dambier -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
- Conclusion 2: There is no reason for standards to uphold the distinction between 1024 and 1024 any more. I agree that the requirement on UNIX-like systems to be root in order to bind to ports 1024 is, in hindsight, a Bad Idea - but mostly because of insufficient privilege granularity. I also think that trusting a source port as an indication of anything is a Bad Idea. However, I do think that it's useful for there to be a range of port numbers that are only bound to a socket if an application specifically asks for one of those ports, as this would reduce the potential for accidental conflicts between servers needing to listen to a well-known port and servers for which any port would do. And it would be appropriate for standards to respect this convention and assign well-known ports in the range of ports that would not be bound by default. I also think that it would be reasonable for an OS to require privileges before it would allow an application to bind to certain ports. But those ports would need to be explicitly enumerated somewhere, rather than merely being a range of numbers. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Title: Re: Guidance needed on well known ports The idea of requiring a privillege to access certain ports can have utility. The idea of requiring root in a monolithic two level system like unix is a very bad one indeed. Http and smtp servers should not run as root. Forcing them to is bad o/s design. -Original Message- From: Andy Bierman [mailto:[EMAIL PROTECTED]] Sent: Mon Mar 20 05:57:34 2006 To: Stephane Bortzmeyer Cc: Ned Freed; ietf@ietf.org Subject: Re: Guidance needed on well known ports Stephane Bortzmeyer wrote: On Sun, Mar 19, 2006 at 12:42:17PM -0800, Ned Freed [EMAIL PROTECTED] wrote a message of 35 lines which said: The privileged port concept has some marginal utility on multiuser systems where you don't Joe-random-user to grab some port for a well known service. had, not has. The concept was invented at a time where multi-users machines were rare and expensive monsters. So, a request coming from source port 513 probably was serious. Today, any highschool student is root on his PC and therefore this protection is almost useless. But does that student have access to the root account on servers which are part of the networking infrastructure? Who cares if Joe User blows up his own config. on a PC that nobody else depends on but Joe? I find the argument flawed -- that because Joe User can be root on his own PC, the concept of privileged access to shared system-critical infrastructure is somehow obsolete. Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
We have to work with what we have here, that unfortunately means original dns plus the srv record. I never cease to be amazed at people who insist on taking things that basically work fairly well and replacing them with more complex mechanisms that are known to work more slowly and less reliably. Probably the worst problem with destination port numbers is that there aren't enough of them. That's probably something that needs to be addressed in TCP and UDP, but a simple extension to each would do the trick. SRV provides fairly limited utility in exchange for the number of problems it presents. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
From: Keith Moore moore@cs.utk.edu Regarding SRV, it's not acceptable to expect that as a condition of deploying a new application, every user who wishes to run that application be able to write to a DNS zone. Most users do not have DNS zones that they can write to. Yes. Architecturally speaking, it's somewhat dubious that information which really only needs to be localized to the host (application-port binding) has to be sent to the DNS. It would be easy to run a tiny little USP binding server that took in an application name (yes, we'd have to register those, but string-space is infinite), and returned the port. About the only reason I can see that that would not be desirable would be to avoid an extra RTT to the do that binding lookup. (DNS/SRV solutions might avoid this RTT too, but in that case that benefit doesn't outweigh the costs.) The obvious way to do it, which is have the ICP use the strings directly (as the CHAOS protocols did) is not really feasible now - it would require a change to TCP. Another option, now that I think about it, though, is a TCP option which contained the service name - one well-known port would be the demux port, and which actual application you connected to would depend on the value in the TCP option. Furthermore it's increasingly necessary that applications be able to work in environments that do not use DNS - such as ad hoc networks or networks that become isolated. Also a good point. Probably the worst problem with destination port numbers is that there aren't enough of them. That's probably something that needs to be addressed in TCP and UDP No, 65K is probably enough (because, recall that a single port can have connections to hundreds of thosands of foreign ports) *provided* that we don't have to assign a well-known port to each application. It's the concept of well-known ports that's broken, not the provision for 65K ports. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
On Mon, 20 Mar 2006 12:47:46 -0500 (EST), [EMAIL PROTECTED] (Noel Chiappa) wrote: Another option, now that I think about it, though, is a TCP option which contained the service name - one well-known port would be the demux port, and which actual application you connected to would depend on the value in the TCP option. Like tcpmux, port 1, RFC 1078? --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
From: Steven M. Bellovin [EMAIL PROTECTED] Another option, now that I think about it, though, is a TCP option which contained the service name - one well-known port would be the demux port, and which actual application you connected to would depend on the value in the TCP option. Like tcpmux, port 1, RFC 1078? You know, as I was typing that, I was thinking I'll bet someone has something that does this, and I just don't know about it, and I'm going to look dumb as toast... Sigh... :-) Which leaves us the obvious question: why aren't more people using TCPMux, if it already exists? Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
It's the concept of well-known ports that's broken, not the provision for 65K ports. offhand I don't see why we need two kinds of names for services, because that creates the need for a way to map from one constant to another - and that mapping causes failures which seem entirely unnecessary. I do see the need to allow applications to talk to non-default service names (say for testing or other special cases) but that's a separate issue. regarding service names, a bit string should be fine, as long as it's not restricted to some short length. 16 bits is not enough in the long term. I don't have much of a problem with services named using character strings either, except that these days such discussions inevitably bring up internationalization issues that I'd rather avoid. most of this is probably moot as I doubt we have the luxury of starting from scratch. but in terms of where we want to be, I think it makes more sense to extend the port # space than to insist that everyone use a separate and less reliable means of mapping between character service names and port #s. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Noel Chiappa wrote: From: Steven M. Bellovin [EMAIL PROTECTED] Another option, now that I think about it, though, is a TCP option which contained the service name - one well-known port would be the demux port, and which actual application you connected to would depend on the value in the TCP option. Like tcpmux, port 1, RFC 1078? You know, as I was typing that, I was thinking I'll bet someone has something that does this, and I just don't know about it, and I'm going to look dumb as toast... Sigh... :-) Which leaves us the obvious question: why aren't more people using TCPMux, if it already exists? Because port 80 exists? Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Ned Freed wrote: But does that student have access to the root account on servers which are part of the networking infrastructure? Who cares if Joe User blows up his own config. on a PC that nobody else depends on but Joe? But if nobody has local access to these servers, why is it is necessary or useful for servers to run with root access in order to bind to these ports? I think the discussion has reinforced and crystallized my personal feeling on the subject: - Services will have to start up listening to specific ports. And in some cases they have to be able to reconfigure to listen on new ports without a full restart. This makes the use root to start then drop it approach problematic in some cases. Whether the port number is specified in an RFC, an SRV record or a config file on a dozen other hosts is in fact irrelevant to the fact that they have to start up knowing what port to listen to (unless they have write access to SRV). Yep. - The root gets to open ports 1024 mechanism is harmful; there are ports 1024 that need to be opened by non-root processes, and ports 1024 that need to be protected from random programs. Agreed. - Conclusion 1: Hosts that care about separation of privileges need to be able to specify access rights on ports as part of their configuration - with can be handed out to processes asking for a port being one particular kind of access right. Yes, and there also needs to be flexibility as to what entities such access rights are given to. Neither a this UID has these rights or this executable has these rights are adequate in all cases, for example. - Conclusion 2: There is no reason for standards to uphold the distinction between 1024 and 1024 any more. Well, there may be some marginal cases left, but if there are they are certainly a minority taste now and their future fate seems certain. And we're definitely at the point where the 1024 approach carries more cost than benefit, so I agree that the time to drop the distinction in our processes is now. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Guidance needed on well known ports
Joe Touch wrote on Monday 20 March 2006: Hallam-Baker, Phillip wrote: From: Joe Touch [mailto:[EMAIL PROTECTED] And with what port would I reach this magical DNS that would provide the SRV record for the DNS itself? You use fixed ports for the bootstrap process and only for the bootstrap process. Which means that the DNS port needs to be well-known or fixed in advance. Some other issues to be considered: - this change would make the DNS required for proper Internet operation, whereas it is currently optional (i.e., only for finding the IP address).] Zeroconf (which is widely deployed for ad-hoc networking and SOHO networks) depends entirely on the premise that there is NO available/configured DNS service. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: [EMAIL PROTECTED] -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.2.5/284 - Release Date: 3/17/2006 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Hallam-Baker, Phillip wrote: The idea of requiring a privillege to access certain ports can have utility. The idea of requiring root in a monolithic two level system like unix is a very bad one indeed. Http and smtp servers should not run as root. Forcing them to is bad o/s design. Bind is chrooted into directory /usr/lib/named and runs as user named. Apache is chrooted into /usr/lib/www and runs as user wwwrun. Exim is chrooted into /usr/lib/exim and runs as user exim. ... There are even systemcalls in all flavours of unix for doing this. There is (almost) no need to run anything as root. Bernstein too has ideas too, how not to run things as root ... Works under all flavours of unix, including MAC OS-X. I guesstimate that works for some 70% of all servers. -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Steven M. Bellovin wrote: On Mon, 20 Mar 2006 12:47:46 -0500 (EST), [EMAIL PROTECTED] (Noel Chiappa) wrote: Another option, now that I think about it, though, is a TCP option which contained the service name - one well-known port would be the demux port, and which actual application you connected to would depend on the value in the TCP option. Like tcpmux, port 1, RFC 1078? --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf How bout the NIS portmapper on port 111 and RFC 1057 -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
- Conclusion 2: There is no reason for standards to uphold the distinction between 1024 and 1024 any more. I agree that the requirement on UNIX-like systems to be root in order to bind to ports 1024 is, in hindsight, a Bad Idea - but mostly because of insufficient privilege granularity. If by insufficient privilege granularity you mean root confers other access, I agree. But while not critical, it would also be useful to have finer granularity in terms of who gets access to what ports. I also think that trusting a source port as an indication of anything is a Bad Idea. You bet. However, I do think that it's useful for there to be a range of port numbers that are only bound to a socket if an application specifically asks for one of those ports, as this would reduce the potential for accidental conflicts between servers needing to listen to a well-known port and servers for which any port would do. And it would be appropriate for standards to respect this convention and assign well-known ports in the range of ports that would not be bound by default. This also sounds reasonable. I also think that it would be reasonable for an OS to require privileges before it would allow an application to bind to certain ports. But those ports would need to be explicitly enumerated somewhere, rather than merely being a range of numbers. Yes, it clearly needs to be fully configurable. Perhaps some of the existing internal firewall configuration mechanisms could be reused here... Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
On Mon, 20 Mar 2006 21:20:04 +0100, Peter Dambier [EMAIL PROTECTED] wrote: How bout the NIS portmapper on port 111 and RFC 1057 Most services do not use RPC. Virtually all of our TCP client-server protocols would run unchanged after connection establishment with TCPMUX. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
It's been suggested to me that RFC 3639 might be relevant to this thread. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
On Mon, 2006-03-20 at 11:51 -0500, Keith Moore wrote: you shouldn't allow unrestricted access to the network from unmanaged hosts, that's a recipe for disaster. no, what's a disaster is to use source IP addresses or port numbers as an indication of trustworthiness on any network that extends beyond a single room. the notion that you can manage significant numbers of hosts to ensure their trustworthiness is delusional. I don't see any contradiction in what you and I are saying, although I would extend single to handful. in any case, it's getting off topic for the issue at hand, so please continue discussion in private if you care to respond. -- Kjetil T. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Hallam-Baker, Phillip wrote: The whole idea of fixed ports is broken. ... The Internet has a signalling layer, the DNS. Applications should use it. The SRV record provides an infinitely extensible mechanism for advertising ports. And with what port would I reach this magical DNS that would provide the SRV record for the DNS itself? Fixed ports do not work behind NAT. Anyone who wants to deploy IPv6 would be well advised to pay careful attention to that restriction. SRV ports work just fine behind a NAT. Except that many NATs also intercept DNS requests and redirect them to their own servers, for their own purposes, which can interfere with SRV records (by design). The only thing that works fine behind a NAT is what the NAT vendor wants to work fine. Everything else is up for grabs. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Guidance needed on well known ports
From: Joe Touch [mailto:[EMAIL PROTECTED] And with what port would I reach this magical DNS that would provide the SRV record for the DNS itself? You use fixed ports for the bootstrap process and only for the bootstrap process. Fixed ports do not work behind NAT. Anyone who wants to deploy IPv6 would be well advised to pay careful attention to that restriction. SRV ports work just fine behind a NAT. Except that many NATs also intercept DNS requests and redirect them to their own servers, for their own purposes, which can interfere with SRV records (by design). People who do this are rarely trying to break things. T The only thing that works fine behind a NAT is what the NAT vendor wants to work fine. Everything else is up for grabs. The NAT vendors would like their systems to work as well as possible. If there had been less hostility to the idea and less determination to ensure IPv4 actually broke thus forcing deployment of IPv6 this could have worked. smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
On Sat, 2006-03-18 at 09:38 -0800, Eliot Lear wrote: This therefore leads to two questions for the community: 1. Are well known ports archaic? If so, can we request that the IANA do away with the distinction? 2. If they are not archaic, under what circumstances should they be allocated? new protocols can not rely on the security the priveleged ports provide, but there are still many such protocols in use (e.g. LPD, port 515), and so the distinction is useful for administrators configuring userspace' access to ports on workstations. The problem is this cuts both way. The privileged port concept has some marginal utility on multiuser systems where you don't Joe-random-user to grab some port for a well known service. OTOH, this forces servers running on those ports to have privileges (usually in the form of running as root) for some period of time. The need to operate with privileges complicates server design, may impose difficult constraints on activities like configuration reloads, and may lead to remote vulnerabilities. So, for a production server with no local users, the privileged port restriction can do much more harm than good. And finally, we have plenty of protocols that make just as much sense on multiuser systems as they do on a production server with no local users. So it is impossible to get this right. The solution is to abandon the coarse grained root-access-to-low-ports security model entirely in favor of some form of finer grained access control. In the meantime, I'm with Harald: Flip a coin and be done with it. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Regardless of what the community consensus is on: 1. Are well known ports archaic? I want to comment that on this: If so, can we request that the IANA do away with the distinction? The IETF decides, and the IANA will then be responsible for implementing the decision. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Hallam-Baker, Phillip wrote: From: Joe Touch [mailto:[EMAIL PROTECTED] And with what port would I reach this magical DNS that would provide the SRV record for the DNS itself? You use fixed ports for the bootstrap process and only for the bootstrap process. Which means that the DNS port needs to be well-known or fixed in advance. Some other issues to be considered: - this change would make the DNS required for proper Internet operation, whereas it is currently optional (i.e., only for finding the IP address).] - hosts may run services but not have control over their own DNS entry (or SRV records) - firewalling based on ports would no longer be useful (one could argue it should not be, but that's a different issue) Fixed ports do not work behind NAT. Anyone who wants to deploy IPv6 would be well advised to pay careful attention to that restriction. SRV ports work just fine behind a NAT. Except that many NATs also intercept DNS requests and redirect them to their own servers, for their own purposes, which can interfere with SRV records (by design). People who do this are rarely trying to break things. They don't *try* to break things, but then tend to. ;-) As to 'by design', they're not so much trying to break as to 'help' (usually for their own purposes). Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Guidance needed on well known ports
1. Are well known ports archaic? If so, can we request that the IANA do away with the distinction? I don't know whether I would use the word archaic, but the distinction between 1024 and = 1024 is certainly Unix-specific. In the Windows operating systems, the port range 1-1023 is not special. Some Windows OS services use low port numbers, but not all. UPNP, for example, uses ports 1900 and 2500; the RPC applications use dynamic port numbers. 2. If they are not archaic, under what circumstances should they be allocated? I have no problem with the current system. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Hi - From: Christian Huitema [EMAIL PROTECTED] To: Eliot Lear [EMAIL PROTECTED]; IETF Discussion ietf@ietf.org Cc: IANA [EMAIL PROTECTED]; Lisa Dusseault [EMAIL PROTECTED]; netconf netconf@ops.ietf.org Sent: Saturday, March 18, 2006 10:44 AM Subject: RE: Guidance needed on well known ports ... 2. If they are not archaic, under what circumstances should they be allocated? I have no problem with the current system. ... So, under the current system (in netconf we're trying to figure out just what that is) should this protocol be assigned a port number above or below 1024? Randy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
On Sat, 18 Mar 2006 10:44:13 -0800, Christian Huitema [EMAIL PROTECTED] wrote: 1. Are well known ports archaic? If so, can we request that the IANA do away with the distinction? I don't know whether I would use the word archaic, but the distinction between 1024 and = 1024 is certainly Unix-specific. In the Windows operating systems, the port range 1-1023 is not special. Some Windows OS services use low port numbers, but not all. UPNP, for example, uses ports 1900 and 2500; the RPC applications use dynamic port numbers. A more interesting question is this: what are the odds that a user process will accidentally grab the port number before the system process gets to it? The notion of a privileged port number is certainly preposterous; that said, putting services in a range that ordinary applications tend not to use has its merits. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Guidance needed on well known ports
A more interesting question is this: what are the odds that a user process will accidentally grab the port number before the system process gets to it? The notion of a privileged port number is certainly preposterous; that said, putting services in a range that ordinary applications tend not to use has its merits. There are two issues there, accidental collision between a dynamic port and a service port, and voluntary collision between applications trying to open the same port. The practical solution to the first problem are to start services and grab ports as part of the boot sequence, i.e. before user processes start, and start dynamic allocations at some high number (e.g. larger than 1024 or larger than 4096 or some admin defined value depending on system version and configuration). If there is a reserved range, then it is easy to start dynamic allocation outside the range. Starting services quickly also helps with the voluntary collisions between system services and applications, but is not foolproof. In any case, it does not help with collisions between applications, e.g. two applications trying to use the same port. What does help there is an easily accessible registration system, so application developers can easily do the right thing, i.e. reserve a port and avoid collisions. Note the emphasis on easily accessible: if there are too many hoops to jump through, the developers will likely just pick a number at random. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
On Sat, 18 Mar 2006 12:41:25 -0800, Christian Huitema [EMAIL PROTECTED] wrote: If there is a reserved range, then it is easy to start dynamic allocation outside the range. Yes -- this is my point. I don't care about Unix-style privileged ports (and have never liked them anyway), but putting most services outside the well-known dynamic range is a good idea. Starting services quickly also helps with the voluntary collisions between system services and applications, but is not foolproof. In any case, it does not help with collisions between applications, e.g. two applications trying to use the same port. What does help there is an easily accessible registration system, so application developers can easily do the right thing, i.e. reserve a port and avoid collisions. Note the emphasis on easily accessible: if there are too many hoops to jump through, the developers will likely just pick a number at random. Right, though it's a delicate dancce. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Guidance needed on well known ports
I would not that starting dynamic ports above 1024 or even above 4096 is not sufficient. There are already services with assigned ports higher than that. And it keeps growing. The IANA list of well-known ports is quite long. If we could go back and start over, something like dynamic DNS and SRV records would get us out of the mess. But that is not a viable choice. Yes, whenever possible one starts services before applications which grab dynamic port numbers. Unfortunately, that sometimes does not work. All that aside, the IANA has a distinction (based on history) between ports below 1024 and those above. And whne asking for a port number assignment, one specifies which range one wants. I had least can not find a coherent strategy for what should be on one side or the other of that boundary. Yours, Joel At 03:41 PM 3/18/2006, Christian Huitema wrote: A more interesting question is this: what are the odds that a user process will accidentally grab the port number before the system process gets to it? The notion of a privileged port number is certainly preposterous; that said, putting services in a range that ordinary applications tend not to use has its merits. There are two issues there, accidental collision between a dynamic port and a service port, and voluntary collision between applications trying to open the same port. The practical solution to the first problem are to start services and grab ports as part of the boot sequence, i.e. before user processes start, and start dynamic allocations at some high number (e.g. larger than 1024 or larger than 4096 or some admin defined value depending on system version and configuration). If there is a reserved range, then it is easy to start dynamic allocation outside the range. Starting services quickly also helps with the voluntary collisions between system services and applications, but is not foolproof. In any case, it does not help with collisions between applications, e.g. two applications trying to use the same port. What does help there is an easily accessible registration system, so application developers can easily do the right thing, i.e. reserve a port and avoid collisions. Note the emphasis on easily accessible: if there are too many hoops to jump through, the developers will likely just pick a number at random. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Guidance needed on well known ports
All that aside, the IANA has a distinction (based on history) between ports below 1024 and those above. And whne asking for a port number assignment, one specifies which range one wants. I had least can not find a coherent strategy for what should be on one side or the other of that boundary. Yours, Joel Do we need one? Or maybe all this distinction is historical? Dan ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Guidance needed on well known ports
The whole idea of fixed ports is broken. The idea that there are only 1024 or even 65535 Internet applications is broken. The Internet has a signalling layer, the DNS. Applications should use it. The SRV record provides an infinitely extensible mechanism for advertising ports. Fixed ports do not work behind NAT. Anyone who wants to deploy IPv6 would be well advised to pay careful attention to that restriction. SRV ports work just fine behind a NAT. IANA should be told to close the well known ports registry. Applications should use DNS SRV records for service location. smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
On Sat, 2006-03-18 at 09:38 -0800, Eliot Lear wrote: This therefore leads to two questions for the community: 1. Are well known ports archaic? If so, can we request that the IANA do away with the distinction? 2. If they are not archaic, under what circumstances should they be allocated? new protocols can not rely on the security the priveleged ports provide, but there are still many such protocols in use (e.g. LPD, port 515), and so the distinction is useful for administrators configuring userspace' access to ports on workstations. My own opinion: They are archaic and the distinction should be dropped. Many operating systems do not make the distinction (particularly special purpose ones) and those that do would be better off providing a finer grain control over what processes can bind to ports. in 2006, if there are DOS or other problems with a protocol which can be solved by using priveleged ports, it shouldn't be published. so it should be a don't care which block is used for allocation these days. -- Kjetil T. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Guidance needed on well known ports
While in general I would like to see this approach taken, this particular case is a perfect example of where I think one can not reasonably do that. The protocol is for the purpose of configuring a router. The router that needs to be configured could easily be between the network engineer and the DNS server. The protocol can not rationally depend upon DNS (no matter how much I like the elegance of removing ports, using dynamic port numbers, and using dynamic DNS.) Yes, we could invent a better way to make things work. And maybe we should. But Netconf should not be held up waiting for that to be developed. Until we develop such a beast, we have to use port numbers. Given that constraint, what guidelines ought to be used for whether a protocol gets a port number above or below 1024? Yours, Joel At 05:09 PM 3/18/2006, Hallam-Baker, Phillip wrote: Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol=application/x-pkcs7-signature; micalg=SHA1; boundary==_NextPart_000_0011_01C64AAE.C23D25B0 The whole idea of fixed ports is broken. The idea that there are only 1024 or even 65535 Internet applications is broken. The Internet has a signalling layer, the DNS. Applications should use it. The SRV record provides an infinitely extensible mechanism for advertising ports. Fixed ports do not work behind NAT. Anyone who wants to deploy IPv6 would be well advised to pay careful attention to that restriction. SRV ports work just fine behind a NAT. IANA should be told to close the well known ports registry. Applications should use DNS SRV records for service location. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
Steven M. Bellovin wrote: On Sat, 18 Mar 2006 12:41:25 -0800, Christian Huitema [EMAIL PROTECTED] wrote: If there is a reserved range, then it is easy to start dynamic allocation outside the range. Yes -- this is my point. I don't care about Unix-style privileged ports (and have never liked them anyway), but putting most services outside the well-known dynamic range is a good idea. Yes, I agree, http should never have been assigned port 80. Randomly looking for ports would make a lot more fun. Maybe it is archaic, that all operating systems treat ports below 1024 special. But still they do. A normal user cannot gain access to these ports. Windows? Is just a randomly changeing mess of dynamic link libraries that is permanently modified by applications, viruses and the so called operating system proper. The api is kept a trade secret. VM, MVS, BS2000, VMS, all flavours of Unix including Minix, MAC OS-X, BSD and Linux treat ports below 1024 special. Special ports are required by servers running on real operating systems. A windows client might be the user of such a port but not the server. Or do you want to install a trunk monkey on every host who takes care of an emerging error window and gives the mouse a push? How about a portmapper. It works with NIS and NFS. Yes the port mapper needs a reserved port too, but that is already allocated. Portmapper is a security hole but so is a randomly changeing mess of DLLs. Starting services quickly also helps with the voluntary collisions between system services and applications, but is not foolproof. In any case, it does not help with collisions between applications, e.g. two applications trying to use the same port. What does help there is an easily accessible registration system, so application developers can easily do the right thing, i.e. reserve a port and avoid collisions. Note the emphasis on easily accessible: if there are too many hoops to jump through, the developers will likely just pick a number at random. The portmapper is such a registration system. I guess the port 42 nameserver was very early allocated and it still works nicely for me but that could not prevent a collision with the peculiar use of port 42 by windows. Right, though it's a delicate dancce. I agree, and please keep http on port 80 :) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf Cheers Peter nd Karin -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
The whole idea of fixed ports is broken. The idea that there are only 1024 or even 65535 Internet applications is broken. agree with you so far. The Internet has a signalling layer, the DNS. Applications should use it. strongly disagree. DNS is a huge mess. It is slow and unreliable. In practice it is often inconsistent both from one query location to another and with reality. only the host knows which application is listening on which port. if there is going to be a layer of indirection between service name and service selector, it's extremely bad design to put that layer of indirection external to the host that's providing the service. (now if you want to argue that an architecture really needs to support clusters of hosts all providing the same service, I'd agree, but DNS is still not a good way to do this.) The SRV record provides an infinitely extensible mechanism for advertising ports. yes, and is not backward compatible with most applications. also, for some reason, few new applications want to use it. Fixed ports do not work behind NAT. irrelevant. lots of things do not work behind NAT. NATs are inherently broken and cannot be fixed. they are an architectural dead end. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Guidance needed on well known ports
This therefore leads to two questions for the community: 1. Are well known ports archaic? If so, can we request that the IANA do away with the distinction? 2. If they are not archaic, under what circumstances should they be allocated? My opinion: they are archaic and should be dropped. A number is a number, and the Unix protection policy has led directly to security exploits because processes were running as root because they had to in order to open a low port number. That said - we need advice on, and probably a distinction between, dynamic ports and ports that you get by asking for them. OSes may also want to attach specific ACLs to specific ports on specific systems - but that's outside of what the IETF has traditionally set standards for. My short term advice to netconf: Flip a coin. Heads, go for a system port. Tails, go for a well known port. It's more important to get past the issue than what you decide. My two cents. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
