All, Since the apparent sticking point in our drive to reduce redundant discovery is the issue of pre-assigned port numbers, I want to write a short description of the issue. I will start at the beginning so we can all be on the same page.
The Internet Assigned Number Authority (IANA) is a division of ICANN, which essentially runs the Internet. If you want a port number for specific use, you ask the IANA for it and justify your need. (I did this in 1990 and got port 128.) Like many Internet resources, the issue is that there are only 65535 numbers, and they have to last as long as the internet. Some numbers are assigned permanently for specific uses (called Well-know or Registered ports); others are allocated temporarily, as needed, which are called Ephemeral ports. One issue is that during the life of the internet, we could run out of numbers. Another issue is that as more permanent allocations are made, there are fewer ports available for temporary/Ephemeral use. Sophisticated network applications have learned to use Ephemeral port allocations to reduce the need for permanent allocations. For example, the HTTP protocol uses two assigned numbers (80 and 443) to handle the billions of web requests daily. Presently, there are quite a few unassigned Registered ports, but remember they have to last forever. IoTivity uses the ports registered for CoAP (5683 and 5684). (I previously advocated registering our own ports for IoTivity since we are not entirely compatible with CoAP usage.) IoTivity uses these ports for discovery, then makes connections on a randomly assigned Ephemeral port. The randomized selection is performed by the network stack, so the port is guaranteed to meet the restrictions of the stack. The discussion about reducing discovery has included the suggestion that some IoTivity applications might benefit from using additional Registered ports for the ongoing connections instead of using Ephemeral ports. It has been suggested that by having access to a small number (5 was mentioned) of Registered ports, IoTivity applications might further reduce discovery, and some arguments have seemed to imply that it might eliminate discovery for those applications. I want to present arguments why IoTivity registering connection port numbers not a good idea. The arguments fall into four categories: * We can't eliminate discovery in any real-world IoTivity system. * IoTivity can't scale properly with any small number of Registered port numbers. * IoTivity shouldn't be in the number allocation business, which the Registered ports would require us to be. * Registered ports provide an easy security attack surface. * Registered ports are a scarce resource, and we shouldn't use them or advocate their use when there are good alternatives available. Before expanding these points, I want to say this: * The current proposal allows the application to set the connection port number. * Any application developer can request a Registered port number from IANA. With the proposal, there is nothing to stop the developer of an IoTivity application from requesting and using a Registered port. My concern is not with using Registered numbers. My concern is that IoTivity shouldn't become a number authority, redistributing numbers that we get from IANA. Doing so sends the wrong message to the vast majority of IoTivity developers, who don't need Registered numbers. Here are expanded discussions of the above reasons why using Registered port number is not a good idea. Eliminating discovery requires fixing both the IP address and port number. Whether the port number is registered or not, IP addresses change. Having both of them unchangeable outside of a laboratory setting is nearly impossible. The fallback is discovery. As long as a client is discovering the IP address, it may as well also discover the port number. Use of registered port numbers by individual applications limits running multiple applications on a single node. Suppose we request five numbers form IANA. Suppose twelve applications want to use them. How do we allocate the five numbers so that any combination of the twelve applications can run on a single node? We may be thinking of only one or two IoTivity applications on a server node now, but in the lifetime of IoTivity, I'm sure there will be more than that. Who is to allocate the five(?) numbers we get? When those numbers are used up, do we attempt to re-use them or do we ask for more? What combination of politics and technical analysis would be used for making that decision? I submit that we can leave allocation of Registered port numbers to IANA. Randomized port numbers can mitigating against some attacks. While monitoring a network can find which ports are used, monitoring takes time. Probing is faster than monitoring, but it only works if you know what numbers to probe. Using registered ports for connections makes probing easier for attackers. Modern network usage has established methods for reducing unnecessary port registrations. We are using those established methods currently. The proposal continues our consistency with established methods while reducing the number of needed discoveries. Reusing the previous port number after a restart reduces the number of restarts drastically, and the optional additional changes reduce the number even further. The proposal on the table can very quickly reduce the number of discoveries. Nothing can eliminate the need for discovery or re-discovery. John Light Intel OTC OCF development. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160506/5fb732d1/attachment.html>
