What is UDP

Comparison of UDP and TCP TCP

Reliable

Ordered

Heavyweight

Streaming

UDP

Unreliable

ordered

Not

Lightweight

Datagrams

Benefits of UDP No connection establishment. Unregulated send rate. support many more active clients

Major Problems of using UDP Reliability Considerations

Lost Datagrams Message Corruption Congestion Control Sequenced Delivery

Security Considerations

Sender Authentication and Message Forgery Message Observation Replaying Unreliable Delivery Message Prioritization and Differentiation Denial of Service

UDP Segment Structure Data :- Length :- UDP Checksum :-

IPv4 IPv6

Destination port Source port

UDP Broadcast Flooding Implementing IP Helper Addressing Implementing UDP Flooding

Encapsulation and Decapsulation Procedures Auxiliary Procedures

Tunnel Mode Decapsulation NAT Procedure

Transport Mode Decapsulation NAT Procedure

Transport Mode ESP Encapsulation Transport Mode ESP Decapsulation Tunnel Mode ESP Encapsulation Tunnel Mode ESP Decapsulation

Reliability and congestion control solutions

UDP hole punching Description Algorithm

Why is a lighter UDP protocol needed?

UDP-Lite

RUDP

Applications

UDP is an acronym for User Datagram Protocol, and it is an integral part of Internet Protocol suite. It was designed by David P. Reed in 1980.UDP is sometimes called the Universal Datagram Protocol.

Fig. : Protocol Stack

UDP is a connectionless transport layer (layer 4) protocol in OSI model, The Internet makes two transport protocols available to its applications, UDP and TCP. UDP provides a simple and unreliable message service for transaction-oriented services. UDP is basically an interface between IP and upper-layer processes. UDP protocol ports distinguish multiple applications running on a single device from one another.

The datagrams sent from one computer to another using UDP may become lost without getting into notice. Moreover, they may arrive in a different order as compared to their order when they were sent.

Time-sensitive applications often use UDP because dropping packets is preferable to waiting for delayed packets, which may not be an option in a real-time system.

The user datagram protocol or UDP, unlike TCP, doesn’t guarantee the correct sequence of transferred data. Moreover, it also doesn’t guarantee any reliability of the data.

Note:-

Connectionless Protocols: - These protocols do not establish a connection between devices. As soon as a device has data to send to another, it just sends it. Service provider usually cannot guarantee that there will be no loss, error insertion, misdelivery, duplication, or out-of-sequence delivery of the packet. No optimizations are possible when sending several frames between the same two peers

TCP Transmission Control Protocol is a connection-oriented protocol,

which means that it requires handshaking to set up end-to-end communications. Once a connection is set up user data may be sent bi-directionally over the connection. Reliable – TCP manages message acknowledgment, retransmission and

timeout. Many attempts to reliably deliver the message are made. If it gets lost along the way, the server will re-request the lost part. In TCP, there's either no missing data, or, in case of multiple timeouts, the connection is dropped.

Ordered – if two messages are sent over a connection in sequence, the first message will reach the receiving application first. When data segments arrive in the wrong order, TCP buffers the out-of-order data until all data can be properly re-ordered and delivered to the application.

Heavyweight – TCP requires three packets to set up a socket connection, before any user data can be sent. TCP handles reliability and congestion control.

Streaming – Data is read as a byte stream, no distinguishing indications are transmitted to signal message (segment) boundaries.

UDP is a simpler message-based connectionless protocol. Connectionless

protocols do not set up a dedicated end-to-end connection. Communication is achieved by transmitting information in one direction from source to destination without verifying the readiness or state of the receiver. Unreliable – When a message is sent, it cannot be known if it will reach its

destination; it could get lost along the way. There is no concept of acknowledgment, retransmission and timeout.

Not ordered – If two messages are sent to the same recipient, the order in which they arrive cannot be predicted.

Lightweight – There is no ordering of messages, no tracking connections, etc. It is a small transport layer designed on top of IP.

Datagrams – Packets are sent individually and are checked for integrity only if they arrive. Packets have definite boundaries which are honored upon receipt, meaning a read operation at the receiver socket will yield an entire message as it was originally sent.

All the above factors might give an impression that UDP is not a handy protocol to use.

However, regardless of its limitations and reliability issues, it still provides considerable benefits that may come handy in different scenarios.

1. No connection establishment. There are no delays as UDP does not need to establish a connection. Thus, an application such as DNS (Domain Name System) would be

much slower over TCP than over UDP.

2. Unregulated send rate. Unlike its TCP counterpart, which has a congestion control mechanism

that throttles the sender when one or more links between the sender and the receiver become congested, UDP has no such restrictions.

These restrictions can seriously affect real-time applications, which may tolerate packet loss but have a minimum send rate.

The capability of UDP to send data is only constrained by the capacity of the applications to generate data.

3. TCP has connection state in the end systems, which includes receiving

and sending buffers, congestion control parameters, and sequence and acknowledgment number parameters.

This state information is needed to implement TCP's reliable data transfer service and to provide congestion control.

UDP, on its part, does not maintain connection state and does not track any of these parameters.

For this reason, a server devoted to a particular application can typically support many more active clients when the application runs over UDP rather than over TCP.

Despite of its benefits, UDP still have some major problems associated with it. One of major concern of using User Datagram Protocol is that it doesn’t offer network congestion control or avoidance mechanism.

Reliability Considerations

The UDP is an unreliable, low-overhead protocol. This section discusses reliability issues inherent in UDP that implementers and users should be aware of.

Lost Datagrams

This transport mapping does not provide any mechanism to detect and

correct loss of datagrams. Datagrams can be lost in transit due to congestion, corruption, or any other intermittent network problem. IP fragmentation exacerbates this problem because loss of a single fragment will result in the entire message being discarded.

Message Corruption

The UDP/IP datagrams can get corrupted in transit due to software,

hardware, or network errors. This transport mapping specifies use of UDP checksums to enable corruption detection in addition to checksums used in IP and Layer 2 protocols. However, checksums do not guarantee corruption detection, and this transport mapping does not provide for message acknowledgement or retransmission mechanism.

Congestion Control

Because syslog can generate unlimited amounts of data, transferring this

data over UDP is generally problematic, because UDP lacks congestion control mechanisms.

Congestion control mechanisms that respond to congestion by reducing traffic rates and establish a degree of fairness between flows that share the same path are vital to the stable operation of the Internet. This is why the syslog TLS (Transport Layer Security) is REQUIRED to implement and RECOMMENDED for general use.

The only environments where the syslog UDP transport MAY be used as an alternative to the TLS transport are managed networks, where the network path has been explicitly provisioned for UDP syslog traffic through traffic engineering mechanisms, such as rate limiting or capacity reservations. In all other environments, the TLS transport SHOULD be used.

Sequenced Delivery

The IP transport used by the UDP does not guarantee that the sequence of

datagram delivery will match the order in which the datagrams were sent. The time stamp contained within each syslog message can serve as a rough guide in establishing sequence order.

However, it will not help in cases where multiple messages were generated during the same time slot, the sender could not generate a time stamp, or messages originated from different hosts whose clocks were not synchronized.

The order of syslog message arrival via this transport SHOULD NOT be used as an authoritative guide in establishing an absolute or relative sequence of events on the syslog sender hosts.

Note:-

syslog is a standard for forwarding log messages in an IP network. The term "syslog" is often used for both the actual syslog protocol, as well as the application or library sending syslog messages. Syslog is a client/server protocol the syslog sender sends a small (less than 1KB) textual message to the syslog receiver. The receiver is commonly called "syslogd", "syslog daemon" or "syslog server". Syslog messages can be sent via UDP and/or TCP. The data is sent in cleartext; although not part of the syslog protocol itself, an SSL wrapper can be used to provide for a layer of encryption through SSL/TLS. Syslog is typically used for computer system management and security auditing. While it has a number of shortcomings, syslog is supported by a wide variety of devices and receivers across multiple platforms. Because of this, syslog can be used to integrate log data from many different types of systems into a central repository.

Security Considerations Using this specification on an unsecured network is NOT RECOMMENDED.

This section focuses on security considerations specific to the syslog transport over UDP. Some of the security issues raised in this section can be mitigated through the use of IPSec as defined in.

Sender Authentication and Message Forgery

This transport mapping does not provide for strong sender authentication. The receiver of the syslog message will not be able to ascertain that the message was indeed sent from the reported sender, or whether the packet was sent from another device. This can also lead to a case of mistaken identity if an inappropriately configured machine sends syslog messages to a receiver representing itself as another machine.

This transport mapping does not provide protection against syslog

message forgery. An attacker can transmit syslog messages (either from the machine from which the messages are purportedly sent or from any other machine) to a receiver.

In one case, an attacker can hide the true nature of an attack amidst

many other messages. As an example, an attacker can start generating forged messages indicating a problem on some machine. This can get the attention of the system administrators, who will spend their time investigating the alleged problem. During this time, the attacker could be able to compromise a different machine or a different process on the same machine.

Additionally, an attacker can generate false syslog messages to give

untrue indications of the status of systems. As an example, an attacker can stop a critical process on a machine, which could generate a notification of exit. The attacker can subsequently generate a forged notification that the process had been restarted. The system administrators could accept that misinformation and not verify that the process had indeed not been restarted.

Message Observation

This transport mapping does not provide confidentiality of the messages in transit. If syslog messages are in clear text, this is how they will be transferred. In most cases, passing clear-text, a human-readable message is a benefit to the administrators.

Unfortunately, an attacker could also be able to observe the human-

readable contents of syslog messages. The attacker could then use the knowledge gained from these messages to compromise a machine.

It is RECOMMENDED that no sensitive information be transmitted via

this transport mapping or that transmission of such information be restricted to properly secured networks.

Replaying

Message forgery and observation can be combined into a replay attack. An attacker could record a set of messages that indicate normal activity of a machine.

At a later time, an attacker could remove that machine from the network

and replay the syslog messages with new time stamps. The administrators could find nothing unusual in the received messages, and their receipt would falsely indicate normal activity of the machine.

Unreliable Delivery

As was previously discussed in Section 4, Reliability Considerations, the UDP transport is not reliable, and packets containing syslog message datagrams can be lost in transit without any notice.

There can be security consequences to the loss of one or more syslog

messages. Administrators could be unaware of a developing and potentially serious problem. Messages could also be intercepted and discarded by an attacker as a way to hide unauthorized activities.

Message Prioritization and Differentiation

This transport mapping does not mandate prioritization of syslog messages either on the wire or when processed on the receiving host based on their severity.

Unless some prioritization is implemented by sender, receiver, and/or

network, the security implication of such behavior is that the syslog receiver or network devices could get overwhelmed with low-severity messages and be forced to discard potentially high-severity messages.

Denial of Service

An attacker could overwhelm a receiver by sending more messages to it

than could be handled by the infrastructure or the device itself. Implementers SHOULD attempt to provide features that minimize this threat, such as optionally restricting reception of messages to a set of known source IP addresses.

In a UDP network, other forms of congestion control mechanism are required to be implemented so that UDP can offer smooth network traffic. One of the potential solutions to this problem is DCCP or the Datagram Congestion Control Protocol which is specifically designed in order to the monitor the traffic running in a UDP network.

The UDP header consists of only 4 fields. Source Port and CheckSum, The use of two of those is optional in IPv4 . In IPv6 only the source port is optional.

32 Bits

Destination Port

Source Port

UDP Checksum

Length

Data . .

UDP segment structure

Data :-

The application data occupies the data field of the UDP datagram :- For example, - For DNS (Domain Name System) , the data field contains either a query

message or a response message. - For a streaming audio application, audio samples fill the data field.

Length :-

It is the length in octets of this user datagram, including this header and the data. In other words, it is the number of bytes comprising the combined UDP

header information and payload data. The minimum value of the length is eight.

UDP Checksum :-

The UDP checksum provides for error detection. Therefore, this protects an application against receiving corrupted payload data in place of, or in addition to, the data that was sent. In the cases where this check is not required, the value of 0x0000 is placed in this field, in which case the data is not checked by the receiver.

- UDP at the sender side performs the one's complement of the sum of all the 16-bit words in the segment. This result is put in the checksum field of the UDP segment.

- When the segment arrives (if it arrives!) at the receiving host, all 16-bit words are added together, including the checksum.

- If this sum equals 1111111111111111, then the segment has no detected errors.

- If one of the bits is a zero, then we know that errors have been introduced into the segment.

As an example, suppose that we have the following three 16-bit words:

0110011001100110 0101010101010101 0000111100001111

The sum of first of these 16-bit words is:

0110011001100110 0101010101010101

--------------------------- 1011101110111011

Adding the third word to the above sum gives

1011101110111011 0000111100001111

---------------------------- 1100101011001010

- The 1's complement is obtained by converting all the 0s to 1s and

converting all the 1s to 0s. - Thus the 1's complement of the sum 1100101011001010 is

0011010100110101, which becomes the checksum. - At the receiver, all four 16-bit words are added, including the checksum. - Internet checksum is not foolproof -- even if the sum equals

111111111111111, it is still possible that there are undetected errors in the segment.

- For this reason, a number of protocols use more sophisticated error detection techniques than simple check summing.

- Although UDP provides error checking, it does not do anything to recover from an error.

IPv4

This is usually an IP header, followed by a UDP header and UDP payload that may be an RTP header and its payload. However, the FULL_HEADER packet may also carry IP Encapsulated packets, in which case there would be two IP headers followed by UDP and possibly RTP

- When UDP runs over IPv4, the checksum is computed using a pseudo-header that contains information from the IPv4 header:

bits 0 - 7 8 - 15 16 - 23 24 - 31

0 Source address

32 Destination address

64 Zeros Protocol UDP length

96 Source Port Destination Port

128 Length Checksum

160

Data

- The source and destination addresses are those in the IPv4 header. The UDP length field is the length of the UDP header and data.

- UDP checksum computation is optional for IPv4. If a checksum is not used it should be set to the value zero.

IPv6

The packet may be built of some combination of IPv6 and IPv4 headers. Each successive header is indicated by the type field of the previous header, as usual.

- When UDP runs over IPv6, the checksum is mandatory. - Any transport or other upper-layer protocol that includes the addresses

from the IP header in its checksum computation must be modified for use over IPv6 to include the 128-bit IPv6 addresses.

- When computing the checksum, a pseudo-header is used that mimics the IPv6 header:

bits 0 - 7 8 - 15 16 - 23 24 - 31

0

Source address 32

64

96

128

Destination address 160

192

224

256 UDP length

288 Zeros Next Header

320 Source Port Destination Port

352 Length Checksum

384

Data

- The source address is the one in the IPv6 header. The destination address is the final destination; if the IPv6 packet doesn't contain a Routing header, that will be the destination address in the IPv6 header; otherwise, at the originating node, it will be the address in the last element of the Routing header, and, at the receiving node, it will be the destination address in the IPv6 header. The UDP length field is the length of the UDP header and data.

Source port

o Source port is an optional field. o When used, it indicates the port of the sending process and may be

assumed to be the port to which a reply should be addressed in the absence of any other information.

o If not used, a value of zero is inserted.

Destination port

o UDP packets from a client use this as a service access point (SAP) to indicate the service required from the remote server.

o UDP packets from a server carry the client SAP in this field.

A broadcast is a data packet that is destined for multiple hosts. Broadcasts

can occur at the data link layer and the network layer. Data-link broadcasts are sent to all hosts attached to a particular physical network. Network layer broadcasts are sent to all hosts attached to a particular logical network

Because broadcasts are recognized by all hosts, a significant goal of router

configuration is to control unnecessary proliferation of broadcast packets. Cisco routers support two kinds of broadcasts: directed and flooded.

A directed broadcast is a packet sent to a specific network or series of

networks, whereas a flooded broadcast is a packet sent to every network. In IP internetworks, most broadcasts take the form of User Datagram Protocol (UDP) broadcasts.

Although current IP implementations use a broadcast address of all ones,

the first IP implementations used a broadcast address of all zeros. Many of the early implementations do not recognize broadcast addresses of all ones and fail to respond to the broadcast correctly. Other early implementations forward broadcasts of all ones,

This causes a serious network overload known as a broadcast storm.

Implementations that exhibit these problems include systems based on versions of BSD UNIX prior to Version 4.3.Two different approaches can be used to configure Cisco routers for forwarding UDP broadcast traffic: IP helper addressing and UDP flooding.

Implementing IP Helper Addressing

IP helper addressing is a form of static addressing that uses directed broadcasts to forward local and all-nets broadcasts to desired destinations within the internet work. IP helper addressing is well-suited to nonredundant, nonparallel topologies that do not require a mechanism for controlling broadcast loops.

Although IP helper addressing is useful in networks that do not require redundancy, when configured in networks that feature redundancy,

IP helper addressing results in packet duplication that severely reduces router and network performance.

Implementing UDP Flooding

UDP flooding uses the spanning tree algorithm to forward packets in a controlled manner. Bridging is enabled on each router interface for the sole purpose of building the spanning tree. The spanning tree prevents loops by stopping a broadcast from being forwarded out an interface on which the broadcast was received. The spanning tree also prevents packet duplication by placing certain interfaces in the blocked state (so that no packets are forwarded) and other interfaces in the forwarding state (so that packets that need to be forwarded are forwarded).

To enable UDP flooding, the router must be running software that supports

transparent bridging and bridging must be configured on each interface that is to participate in the flooding. If bridging is not configured for an interface, the interface will receive broadcasts, but the router will not forward those broadcasts and will not use that interface as a destination for sending broadcasts received on a different interface. Note Releases prior to Cisco Internetwork Operating System (Cisco IOS) Software Release 10.2 do not support flooding subnet broadcasts.

When configured for UPD flooding, the router uses the destination address

specified by the ip broadcast-address command on the output interface to assign a destination address to a flooded UDP datagram. Thus, the destination address might change as the datagram propagates through the network. The source address, however, does not change. With UDP flooding, both routers shown in Figure 19-1 use a spanning tree to control the network topology for the purpose of forwarding broadcasts

By configuring UDP flooding, one router forwards UDP traffic without

burdening the second router with duplicate packets. By dedicating one router to the task of forwarding UDP traffic, the second router becomes available for forwarding unicast traffic. At the same time, because each router is configured as the backup for the other router, redundancy is maintained; if either router fails, the other router can assume the work of the failed router without intervention from an operator. When compared with IP helper addressing, UDP flooding makes the most efficient use of router resources.

Auxiliary Procedures

1. Tunnel Mode Decapsulation NAT Procedure When a tunnel mode has been used to transmit packets the inner IP header can contain addresses that are not suitable for the current network. This procedure defines how these addresses are to be converted to suitable addresses for the current network. Depending on local policy, one of the following MUST be done: 1. If a valid source IP address space has been defined in the policy for the

encapsulated packets from the peer, check that the source IP address of the inner packet is valid according to the policy.

2. If an address has been assigned for the remote peer, check that the source IP address used in the inner packet is the assigned IP address.

3. NAT is performed for the packet, making it suitable for transport in the local network.

2. Transport Mode Decapsulation NAT Procedure

When a transport mode has been used to transmit packets, contained TCP or UDP headers will have incorrect checksums due to the change of parts of the IP header during transit. This procedure defines how to fix these checksums .Depending on local policy; one of the following MUST be done: 1. If the protocol header after the ESP header is a TCP/UDP header and the

peer’s real source and destination IP address have been received according to incrementally recompute the TCP/UDP checksum: * Subtract the IP source address in the received packet from the checksum. * Add the real IP source address received via IKE to the checksum * Subtract the IP destination address in the received packet from the checksum.

NAT (Network Address Translation)

Internet Key Exchange (IKE or IKEv2) is the protocol used to set up a security association (SA) in the IPSec protocol suite.

* Add the real IP destination address received via IKE to the checksum

Note: If the received and real address are the same for a given address (e.g., say the source address), the operations cancel and don’t need to be performed.

2. If the protocol header after the ESP header is a TCP/UDP header, recompute the checksum field in the TCP/UDP header.

3. If the protocol header after the ESP header is a UDP header, set the checksum field to zero in the UDP header. If the protocol after the ESP header is a TCP header, and if there is an option to flag to the stack that the TCP checksum does not need to be computed, then that flag MAY be used. This SHOULD only be done for transport mode, and if the packet is integrity protected. Tunnel mode TCP checksums MUST be verified.

Transport Mode ESP Encapsulation BEFORE APPLYING ESP/UDP ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING ESP/UDP ------------------------------------------------------------- IPv4 |orig IP hdr | UDP | Non-| ESP | | | ESP | ESP| |(any options)| Hdr | IKE | Hdr | TCP | Data | Trailer |Auth| ------------------------------------------------------------- |<----- encrypted ---->| |<------ authenticated ----->|

1) Ordinary ESP encapsulation procedure is used. 2) A properly formatted UDP header and a Non-IKE Marker are inserted where

shown. 3) The Total Length, Protocol and Header Checksum fields in the IP header are

edited to match the resulting IP packet.

Transport Mode ESP Decapsulation

1) The UDP header and the Non-IKE Marker are removed from the packet. 2) The Total Length, Protocol and Header Checksum fields in the new IP

header are edited to match the resulting IP packet. 3) Ordinary ESP decapsulation procedure is used. 4) Transport mode decapsulation NAT procedure is used.

Tunnel Mode ESP Encapsulation

BEFORE APPLYING ESP/UDP ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPLYING ESP/UDP -------------------------------------------------------------------- IPv4 |new h.| UDP | Non-| ESP |orig IP hdr | | | ESP | ESP| |(opts)| Hdr | IKE | Hdr |(any options)| TCP | Data | Trailer |Auth| -------------------------------------------------------------------- |<------------ encrypted ----------->| |<------------- authenticated ------------>|

1) Ordinary ESP encapsulation procedure is used. 2) A properly formatted UDP header and a Non-IKE Marker are inserted where

shown. 3) The Total Length, Protocol and Header Checksum fields in the new IP

header are edited to match the resulting IP packet.

Tunnel Mode ESP Decapsulation

1) The UDP header and the Non-IKE Marker are removed from the packet. 2) The Total Length, Protocol and Header Checksum fields in the new IP header are edited to match the resulting IP packet. 3) Ordinary ESP decapsulation procedure is used. 4) Tunnel mode decapsulation NAT procedure is used.

Lacking reliability, UDP applications must generally be willing to accept some loss, errors or duplication. Some applications such as TFTP may add rudimentary reliability mechanisms into the application layer as needed.

Most often, UDP applications do not require reliability mechanisms and may even be hindered by them. Streaming, real-time multiplayer games and voice over IP (VoIP) are examples of applications that often use UDP.

If an application requires a high degree of reliability, a protocol such as the Transmission Control Protocol or erasure codes may be used instead.

Lacking any congestion avoidance and control mechanisms, network-based mechanisms are required to minimize potential congestion collapse effects of uncontrolled, high rate UDP traffic loads.

In other words, since UDP senders cannot detect congestion, network-based elements such as routers using packet queuing and dropping techniques will often be the only tool available to slow down excessive UDP traffic. The Datagram Congestion Control Protocol (DCCP) is being designed as a partial solution to this potential problem by adding end host TCP-friendly congestion control behavior to high-rate UDP streams such as streaming media.

UDP hole punching is a commonly used NAT (Network Address Translation) traversal technique. NAT traversal is a general term for techniques that establish and maintain TCP/IP network and/or UDP connections traversing network address translation (NAT) gateways.

NAT traversal techniques are typically required for client-to-client networking applications, especially peer-to-peer and Voice-over-IP (VoIP) deployments.

Description

(UDP) hole punching is a method for establishing bidirectional UDP connections between Internet hosts in private networks using NAT. It does not work with all types of NATs as their behavior is not standardized.

Each host behind a NAT contacts a third, well-known server (usually a STUN server) in the public address space and then, once the NAT devices have established UDP state information, switches to direct communication hoping that the NAT devices will keep the states despite the packets coming from a different host.

UDP hole punching will not work with a Symmetric NAT (also known as bi-directional NAT) which tends to be found inside large corporate networks. With Symmetric NAT, the NAT's mapping associated with the connection to the well known server is restricted to receiving data from the well known server, and therefore the NAT mapping the well known server sees is not useful information to the endpoint. For details on the different types of NAT.

A STUN (Simple Traversal of User Datagram Protocol [UDP] Through Network Address Translators [NATs]) server allows NAT clients (i.e. computers behind a firewall) to setup phone calls to a VOIP provider hosted outside of the local network.

In a somewhat more elaborate approach both hosts will start sending to each other, using multiple attempts. On a Restricted Cone NAT, the first packet from the other host will be blocked. After that the NAT device has a record of having sent a packet to the other machine, and will let any packets coming from these IP address and port number through.

The technique is widely used in peer-to-peer software and Voice over Internet Protocol telephony. It is one of the methods used in Skype to communicate without bypassing firewalls or NAT. It can also be used to assist the establishment of virtual private networks operating over UDP. The same technique is sometimes extended to Transmission Control Protocol (TCP) connections, albeit with much less success.

Algorithm

Let A and B be the two hosts, each in its own private network; N1 and N2 are the two NAT devices; S is a public server with a well-known globally reachable IP address.

1. A and B each begin a UDP conversation with S; the NAT devices N1 and N2 create UDP translation states and assign temporary external port numbers .

2. S relays these port numbers back to A and B . 3. A and B contact each others' NAT devices directly on the translated

ports; the NAT devices use the previously created translation states and send the packets to A and B.

The problem is that today's Internet protocols have been designed for connections characterized by:

high-bandwidth; low-delay; low frequency of errors;

To accommodate wireless mobile devices (portable computers, PDAs, cellular phones) for which the connections are characterized by: low-bandwidth; high-delay; high frequency of errors;

Audio/video applications often prefer damaged data over no data since the use of clever codecs can cope for the error. Disabling UDP checksum is not an option since headers would go unverified and packets might be misdelivered. Also in IPv6 the UDP checksum is mandatory.

A special class of applications can derive benefit from having partially damaged payloads delivered, rather than discarded, when using paths that include error-prone links. Such applications can tolerate payload corruption and may choose to use the Lightweight User Datagram Protocol (UDP-Lite) variant of UDP instead of basic UDP.

The header format closely follows that of UDP. UDP-Lite changes the semantics of the UDP "payload length" field to that of a:

"Checksum coverage length" field. Otherwise, UDP-Lite is identical to UDP. The interface of UDP-Lite differs from that of UDP by the addition of a single (socket) option that communicates a checksum coverage length value: at the sender, this specifies the intended checksum coverage, with the remaining

unprotected part of the payload called the "error insensitive part".

By default, the UDP-Lite checksum coverage extends across the entire datagram. If required, an application may dynamically modify this length value, e.g., to offer greater protection to some messages.

UDP-Lite always verifies that a packet was delivered to the intended destination, i.e., always verifies the header fields. Errors in the insensitive part will not cause a UDP datagram to be discarded by the destination.

Applications using UDP-Lite therefore must not make assumptions regarding the correctness of the data received in the insensitive part of the UDP-Lite payload (this may have been changed). The sending application therefore needs to specify a minimum checksum coverage that include all sensitive protocol headers.

Reliable UDP (RUDP) is a simple packet based transport protocol, which is intended as a reliable protocol to transport telephony signaling across IP networks. RUDP is designed to allow characteristics of each connection to be individually configured so that a number of protocols with different transport requirement can be implemented simultaneously not on the same platform.

It is layered on the UDP/IP protocols and provides reliable in-order delivery (up to a maximum number of retransmissions) for virtual connections. RUDP has a very flexible design that would make it suitable for a variety of transport uses. One such use would be to transport telecommunication-signaling protocols.

Reliable UDP (RUDP) is a set of quality of service enhancements, such as congestion control tuning improvements, retransmit, and thinning server algorithms, that improve the ability to present a good quality RTP stream to RTP clients even in the presence of packet loss and network congestion. Reliable UDP's congestion control mechanisms allow streams to behave in a TCP-friendly fashion without disturbing the real-time nature of the protocol.

To work well with TCP traffic on the Internet, RUDP (Reliable UDP) uses retransmission and congestion control algorithms similar to the algorithms used by TCP. Additionally, these algorithms are time-tested to utilize available bandwidth optimally.

Reliable UDP (RUDP) features include:

Client acknowledgment of packets sent by the server to the client Windowing and congestion control so the server does not exceed the

currently available bandwidth Server retransmission to the client in the event of packet loss Faster than real-time streaming known as over buffering

Voice and video traffic is generally transmitted using UDP.Real-time video and audio streaming protocols are designed to handle occasional lost packets, so only slight degradation in quality occurs rather than large delays if lost packets are retransmitted.

Because both TCP and UDP run over the same network, many businesses are finding that a recent increase in UDP traffic from these real-time applications is hindering the performance of applications using TCP, such as point of sale, accounting, and database systems.

When TCP detects packet loss, it will throttle back its data rate usage. Since both real-time and business applications are important to businesses, developing quality of service solutions is crucial.