-
Notifications
You must be signed in to change notification settings - Fork 0
Registered Port Number
On 18th August 2015 IANA officially assigned the registered UDP port number 4412 to SmallChat, according to RFC 6335.
The case-insensitive service name assigned to SmallChat is smallchat.
Port numbers between 1 and 1023 (well-known ports) are used by standard protocols, such as HTTP (port 80).
Ports between 1024 and 49151 are user ports.
User ports are assigned by IANA and should not be used if not registered by IANA (although it's possible).
Many ports actually have known or not known unofficial uses, but registering a port number reduces the chance of conflict.
The procedure for a port number registration is described in RFC 6335.
One must send IANA a request using a web form and all requests are then reviewed by the IESG-designated Port Experts team for approval.
The request might or might not be approved using three processes, called IETF Review, IESG Approval and Expert Review.
A list of all registered ports is available here.
On 7th July 2015 Valentino Giudice sent this application to IANA for a port number and service name (some information may no longer be true):
Application for a Port Number and/or Service Name
Assignee: Valentino Giudice valentino.giudice@vallauri.edu Contact Person: Valentino Giudice valentino.giudice96@gmail.com
Resource Request:
[x] Port Number [x] Service Name
Transport Protocols: [ ] TCP [x] UDP [ ] SCTP [ ] DCCP
Service Code: [] Service Name: [SmallChat] Desired Port Number: [] Description: [SmallChat is a peer to peer UDP-based protocol initially designed to create a local network chat without needing to be connected to the Internet. Now, it can actually also be used for communicating with hosts outside the network.]
Reference: [Each PDU contains:
- The "chatID" field
- The type of PDU
- The encoding used in the payload of the PDU
- The payload of the PDU.
The chatID identifies the communication, while each host is identified by a "nickname" (sent during the discovery). There can be multiple communications on the same network and on the same port as long as the chatID is not the same (see "Please explain why a unique port assignment is necessary as opposed to a port in range (49152-65535) or existing port"). All other fields are encrypted using a symmetric key algorithm (the key, as well as the chatID, has to be agreed upon users).
A PDU can be of five different types:
- Hello ("HLO"): they are used to discover other hosts to communicate with.
- Welcome ("ACK"): they are sent as a response to Hello PDUs.
- Leave ("LEV"): they are sent by hosts which are leaving the communication.
- Message ("MSG"): they are used to send ordinary chat messages to other hosts.
- Malformed PDU notifications ("BAD"): they are sent as a response to broken PDUs and PDUs which have been encrypted with the wrong key.
- Nickname conflict notifications ("CNF"): are sent when the IPs of two different hosts are associated with the same nickname to the involved hosts.
The payload of BAD notifications (which is the full binary received PDU) is not encrypted because:
- It has probably already been encrypted by the sender.
- If the sender has used the wrong key, it wouldn't be able to decrypt them.
- You don't want anyone to know how a certain message looks like if encrypted with your secret key (this one is not actually a good reason: see "Please describe how your protocol supports security").
Of course, if two hosts, for some reasons, use different keys, this could, theoretically, produce an infinite amount of BAD notifications, causing congestion. To prevent that, each host can only send up to 4 BAD notifications each 10 minutes (if a host cannot send the notification immediately, it will not send it at all).
CNF notifications are sent if two hosts have the same nickname (which can be noticed during the discovery) to the two interested hosts. There is no need to also inform other hosts because each host which is taking part in the communication is well-trusted since it has the encryption key.
Each host has a list of other hosts which is updated by adding a host (and its nickname) when HLO or ACK PDUs are received or by removing it when a LEV PDU is received.
Nicknames are just sent in HLO and ACK PDUs (as the payload), then there is no need to send them.
The first HLO PDU is usually sent in broadcast in the current network, but it can also be sent to hosts outside the network, so the communication is not necessarily limited to a single network.
Of course, even though SmallChat has been designed to create chat applications, it can also be used for other purposes (in general, when a peer to peer communication in a local network is needed).]
Defined TXT Keys:
If broadcast/multicast is used, how and what for? [SmallChat is a peer to peer protocol and broadcast is used by hosts to discover other hosts before communicating with them. During actual communication unicast messages are used.]
If UDP is requested, please explain how traffic is limited, and whether the protocol reacts to congestion. [The protocol does not react to congestion, but it does prevent it by limiting the number of notifications each host can send during a certain amount of time. There is no actual need of reducing traffic.]
If UDP is requested, please indicate whether the service is solely for the discovery of hosts supporting this protocol. [UDP is currently using both for discovery and for actual communication.]
Please explain how your protocol supports versioning. [There may not be future versions at all and versioning might not be supported, but please also see "Please explain the state of development of your protocol".]
If your request is for more than one transport, please explain in detail how the protocol differs over each transport. [SmallChat currently only uses UDP. Future versions might use UDP for discovery and TCP for actual communication.]
Please describe how your protocol supports security. Note that presently there is no IETF consensus on when it is appropriate to use a second port for an insecure version of a protocol. [All messages are encrypted using SCEDA (SmallChat Encryption- Decryption Algorithm), a symmetric key encryption technique, built in a particular way so that the same message, encrypted with the same key, can look very differently each time (making statistical attacks impossible).]
Please explain why a unique port assignment is necessary as opposed to a port in range (49152-65535) or existing port. [A unique port assignment would be useful because all hosts would use the same port and, therefore, messages would just have to be sent to this port. Still, independent communications would be allowed on the same network thanks to the chatID field.]
Please explain the state of development of your protocol. [The protocol has been theoretically developed and also fully implemented in C language (the code works on UNIX-like OSs) and C# language, but it will probably be slightly modified in order for it to be lighter. Also, in the header of SmallChat PDUs a field indicating the protocol version will probably be added, so that future implementations of SmallChat will be compatible with older ones. Of course, since the protocol is the same, if a host uses the C implementation, it has no problem communicating with hosts which use the C# implementation.]
If SCTP is requested, is there an existing TCP and/or UDP service name or port number assignment? If yes, provide the existing service name and port number. []
What specific SCTP capability is used by the application such that a user who has the choice of both TCP (and/or UDP) and SCTP ports for this application would choose SCTP? See RFC 4960 section 7.1. []
Please provide any other information that would be helpful in understanding how this protocol differs from existing assigned services. [There are lots of protocols used for chats (like IRC or MUD), but they are usually not peer to peer. Also, unlike other protocols, SmallChat allows an undetermined number of hosts to communicate with each other.]
The request has been officially approved on 18th August 2015 and SmallChat was assigned the 4412 UDP port and the service name smallchat.