Académique Documents
Professionnel Documents
Culture Documents
Submitted By:
Diane Aclo
Jerome Cansado
Ed Lorence De Guzman
Christian Glenn Hatol
Sean Francis Natividad
Aeysol Rosaldo
APPLICATION LAYER
Simple Sensor Interface Protocol
The SSI protocol is asynchronous and stateless. The SSI protocol command
structure consists of three parts:
Header
Payload
Optional CRC checksum.
The header structure and length may change from case to case, but the
payload structure is always the same. Here are presented two different five
byte header structures; UART (point-to-point) connection and embedded
networking (nanoIP). The SSI protocol byte order is Big Endian (most
significant byte first).
The optional CRC checksum is present in the message frame only when the
command code is written in lower case (a-z). The CRC checksum is
calculated over the payload part. If the CRC is not correct, the message has
to be ignored.
When a node sends a packet using the SSI protocol over nanoIP, the SSI
protocol frame will be encapsulated in a nanoUDP header (5 bytes), which
contains the length and 40 (0x28) for the source and destination ports.
Session Initiation Protocol
SIP, the session initiation protocol, is the IETF protocol for VOIP and other text
and multimedia sessions, like instant messaging, video, online games and
other services.
SIP is very much like HTTP, the Web protocol, or SMTP. Messages consist of
headers and a message body. SIP message bodies for phone calls are defined
in SDP -the session description protocol. SIP is a text-based protocol that
uses UTF-8 encoding. It uses port 5060 both for UDP and TCP.
SIP offers all potentialities of the common Internet Telephony features like:
call or media transfer
call conference
call hold
Since SIP is a flexible protocol, it is possible to add more features and keep
downward interoperability. However, it also does suffer from NAT or firewall
restrictions.
SIP can be regarded as the enabler protocol for telephony and voice over IP
(VoIP) services. The following features of SIP play a major role in the
enablement of IP telephony and VoIP:
Name Translation and User Location: Ensuring that the call reaches the
called party wherever they are located. Carrying out any mapping of
descriptive information to location information. Ensuring that details of
the nature of the call (Session) are supported.
Feature Negotiation: This allows the group involved in a call (this may
be a multi-party call) to agree on the features supported
recognizing that not all the parties can support the same level of
features. For example video may or may not be supported; as any form
of MIME type is supported by SIP, there is plenty of scope for
negotiation.
Call Participant Management: During a call a participant can bring
other users onto the call or cancel connections to other users. In
addition, users could be transferred or placed on hold.
Call feature changes: A user should be able to change the call
characteristics during the course of the call. For example, a call may
have been set up as 'voice-only', but in the course of the call, the users
may need to enable a video function. A third party joining a call may
TRANSPORT LAYER
Hybrid Transport Layer Security Protocol
TLS (Transport Layer Security) protocol supports reliable transport layer
protocols (e.g. TCP, Multipath TCP, SCTP, RUDP) is made up of two main
components:
Based on TLS and WTLS, HTLS is also a layered protocol which basically has to
functions:
Same as WTLS, HTLS is also composed of HTLS record protocol which is further
divided into six sub-protocols; the handshake protocol, the cipher protocol,
the alert protocol,
the
group control protocol ,
the
encryption synchronization protocol and the application data protocol.
In the record protocol, the end applications share a secret key and public key
pair and are identified as either client or server. Data can be encrypted using either
single or multiple encryptions when symmetric and asymmetric key algorithms are
chosen. MAC and compression algorithms are defined and random bytes are
assigned to both client and server. The HTLS record protocol parameters are
received by the handshake protocol.
Record fragmentation, compression, decompression and data protection follow
the same principle as in WTLS. However, the HTLS record protocol supports multiple
encryptions at this level. Messages can be encrypted with symmetric and
asymmetric key encryption when there is high sensitivity of data. In such
circumstances, the message is first encrypted with a symmetric key algorithm and
then with an asymmetric key algorithm, similar to the certificate
generation/verification process.
The HTLS handshake protocol is responsible for negotiating a secure session.
It is composed of four sub protocols, which are used to allow both parties to agree
upon security parameters for the record layer, to authenticate each other and to
report error conditions to each other. The parameters are as shown in Table 1.
The start messages are used by the client and the server to agree on a protocol
version, session identification, authentication type and exchange information such
as random numbers, public and secret keys, and performance parameters.
The cipher protocol consists of a single encrypted message (or cipher spec)
which is sent to the end application either by the client or the server. It can be sent
during the handshake or the data transfer phase. When it arrives, the sender waits
for a response and the receiver initializes or updates the secure parameters.
The alert protocol translates the severity of messages and gives a description
of the alert. It consists of two parameters:
When the client wishes to resume a secure session, it sends a client start
message using the session ID. The server then checks its secure session cache for a
match. If a match is found and the session is can be resumed, then the server could
re-establish the secure session by sending the server start message with the same
session ID. The server sends a cipher spec message. Once the re-establishment is
complete, the client and server can start the exchange application data.
The application data protocol will be responsible for delivering correct
information to the end applications and for identifying changes to it. Unlike TLS and
WTLS, HTLS performs integrity check on the sent or received information even on
established secure connections.
Allowing anonymous connections to be established can be very risky
because anonymous authentication increases the chances for intruder-in-the-middle
attacks. Both the client and the server should always authenticate each other
before a key exchange for intruder attacks. Currently, in WTLS request for certificate
of authentication is optional for the client unlike in HTLS which needs authentication
from both client and server.
INTERNET LAYER
The Internet layer in the TCP/IP reference model is responsible for
transferring data between the source and destination computers. The
Internet layer accepts data from the Transport layer and passes the data to
the Network Interface layer. The following are the functions of the Internet
layer:
Routing the data to the correct destination. This layer takes care
of sending the data through the shortest route if more than one
route is available. In addition, if a route through which a
datagram is to be sent has problems, the datagram is sent
through an alternate route.
Figure 10: Internet protocols span the complete range of OSI model layers.
The total size of the ethernet frame must be between 64 bytes and 1,518
bytes (not including the preamble). A frame shorter than the minimum 64
bytes but with a valid CRC is called as a runt. In most cases, such frames
arise from a collision. Any frame which is received and which is greater than
the maximum frame size, is called a "giant". A "giant" is longer than 1518
bytes yet have a valid CRC. Both runts and giants are considered as invalid.
Figure
11: Structure of an Ethernet Frame
Sources:
http://www.janding.fi/iiro/papers/SSI%20protocol
%20specification_12.pdf
http://www.voip-info.org/wiki/view/SIP
http://moodle.cs.ucy.ac.cy/pluginfile.php?file=
%2F7468%2Fmod_resource%2Fcontent%2F0%2FHTLS.pdf
http://fab.cba.mit.edu/classes/MIT/961.04/people/neil/ip.pdf
http://www.omnisecu.com/tcpip/network-access-layer.php
http://www.tummy.com/articles/networking-basics-how-arp-works/