쥐스킨트의 작은 서재

Temporal Key Integrity Protocol

Temporal Key Integrity Protocol or TKIP was a stop gap security protocol used in the IEEE 802.11 wireless networking standard. TKIP was designed by the IEEE 802.11i task group and the Wi-Fi Alliance as an interim solution to replace WEP without requiring there placement of legacy hardware. This was necessary because the breaking of WEP had left WiFi networks without viable link-layer security, and a solution was required for already deployed hardware. TKIP is no longer considered secure and was deprecated in the 2012 revision of the 802.11 standard.

Security

TKIP uses the same underlying mechanism as WEP, and consequently is vulnerable to a number of similar attacks. The message integrity check, per-packet key hashing, broadcast key rotation, and a sequence counter discourage many attacks. The key mixing function also eliminates the WEP key recovery attacks.

Locator/Identifier Separation Protocol

Locator/ID Separation Protocol (LISP) is a “map-and-encapsulate” protocol which is developed by the Internet Engineering Task Force LISP WorkingGroup. The basic idea behind the separation is that the Internet architecture combines two functions, routing locators (where a client is attached to the network) and identifiers (who the client is) in one number space: the IP address. LISP supports the separation of the IPv4 and IPv6 address space following a network-based map-and-encapsulate scheme. In LISP, both identifiers and locators can be IP addresses or  arbitrary elements like a set of GPS coordinates or MAC address.

Session Initiation Protocol

The Session Initiation Protocol (SIP) is acommunications protocol for signaling and controlling multimedia communicationsessions. The most common applications of SIP are in Internet telephony forvoice and video calls, as well as instant messaging, over Internet Protocol(IP) networks.

The protocol defines the messages that aresent between endpoints, which govern establishment, termination and otheressential elements of a call. SIP can be used for creating, modifying andterminating sessions consisting of one or several media streams. SIP is anapplication layer protocol designed to be independent of the underlyingtransport layer. It is a text-based protocol, incorporating many elements ofthe Hypertext Transfer Protocol (HTTP) and the Simple Mail Transfer Protocol(SMTP).

SIP works in conjunction with several otherapplication layer protocols that identify and carry the session media. Media identificationand negotiation is achieved with the Session Description Protocol (SDP). Forthe transmission of media streams (voice, video) SIP typically employs theReal-time Transport Protocol (RTP) or Secure Real-time Transport Protocol(SRTP). For secure transmissions of SIP messages, the protocol may be encryptedwith Transport Layer Security (TLS).

Token ring

Token ring local area network (LAN) technology is a communications protocol for local area networks. It uses a special three-byte frame called a “token” that travels around a logical “ring”of work stations or servers. This token passing is a channel access method providing fair access for all stations, and eliminating the collisions of contention-based access methods.

Comparison with Ethernet

Ethernet and Token ring have some notable differences:

-      Token Ring access is more deterministic, compared to Ethernet’s contention-based CSMA/CD

-      Ethernet supports a directcable connection between two network interface cards by the use of a crossover cable or through auto-sensing if supported. Token ring does not inherently support this feature and requires additional software and hardware to operateon a direct cable connection setup.

-      Token ring eliminate collision by the use of a single-use token and early token and early token release to alleviate the down time. Ethernet alleviates collision by carrier sense multiple access and by the use of an intelligent switch; primitive Ethernet devices like hubs can precipitate collisions due to repeating traffic blindly.

Stream Control Transmission Protocol

In computer networking, the Stream Control Transmission Protocol (SCTP) is a transport-layer protocol, serving in a similar role to the popular protocols TCP and UDP.

SCTP provides some of the same service features of both: it is message-oriented like UDP and ensures reliable, in-sequence transport of messages with congestion control like TCP; it differs from these in providing multi-homing and redundant paths to increase resilience and reliability.

In the absence of native SCTP support in operating systems it is possible to tunnel SCTP over UDP, as well as mapping TCP API calls to SCTP ones. The reference implementation was released as part of FreeBSD version 7. It has subsequently been widely ported.

Real-time Transport Protocol

The Real-time Transport Protocol (RTP) is a network protocol for delivering audio and video over IP networks. RTP is used extensively in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications, television services and web-based push-to-talk features.

RTP is used in conjunction with the RTP Control Protocol (RTCP). While RTP carries the media streams (e.g., audio and video), RTCP is used to monitor transmission statistics and quality of service (QoS) and aids synchronization of multiple streams. RTP is one of the technical foundations of Voice over IP and in this context is often used in conjunction witha signaling protocol such as the Session Initiation Protocol (SIP) which establishes connections across the network.

Overview

RTP is designed for end-to-end, real-time, transfer of streaming media. The protocol provides facilities for jitter compensation and detection of out of sequence arrival in data, which are common during transmission on an IP network. RTP allows data transfer to multiple destinations through IP multicast. RTP is regarded as the primary standard for audio/video transport in IP networks and is used with an associated profile and payload format.

Real-time multimedia streaming applications require timely delivery of information and often can tolerate some packet lossto achieve this goal. For example, loss of a packet in audio application may result in loss of a fraction of a second of audio data, which can be made unnoticeable with suitable error concealment algorithms. The Transmission Control Protocol (TCP), although standardized for RTP use, is not normally used in RTP applications because TCP favors reliability over timeliness. Instead themajority of the RTP implementations are built on the User Datagram Protocol(UDP). Other transport protocols specifically designed for multimedia sessions are SCTP and DCCP, although, as of 2010, they are not in widespread use.

Protocol components

The RTP specification describes two sub-protocols, RTP and RTCP.

The data transfer protocol, RTP, facilitates the transfer of real-time data. Information provided by this protocol include timestamps, sequence numbers and the payload format which indicates the encoded format of the data.

The control protocol RTCP is used tospecify quality of service (QoS) feedback and synchronization between the media streams. The bandwidth of RTCP traffic compared to RTP is small, typically around 5%.

Hypertext Transfer Protocol

The Hypertext Transfer Protocol (HTTP) is an application protocol for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web.

Hypertext is structured text that uses logical links (hyperlinks) between nodes containing text. HTTP is the protocol to exchange or transfer hypertext.

Development of HTTP was initiated by Tim Berners-Lee at CERN in 1989. Standards development of HTTP was coordinated by the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C), culminating in the publication of a series of Requests for Comments (RFCs). The first definition of HTTP/1.1, the version of HTTP in common use, occurred in RFC 2068 in 1997, although this was obsoleted by RFC 2616 in 1999.

A later version, the successor HTTP/2, was standardized in 2015, then supported by major web browsers and already supported by major web servers.

Technical overview

HTTP functions as a request-response protocol in the client-server computing model. A web browser, for example, may be the client and an application running on a computer hosting a web site may be the server. The server, which provides resources such as HTML files and other content or performs other functions on behalf of the client, returns a response message to the client. The response contains completion status information about the request and may also contain requested content in its message body.

A web browser is an example of a user agent (UA). Other types of user agent include the indexing software used by search providers (web crawlers), voice browsers, mobile apps, and other software that accesses, consumes, or displays web content.

HTTP is designed to permit intermediate network elements to improve or enable communications between clients andservers. High-traffic websites often benefit from web cache servers that deliver content on behalf of upstream servers to improve response time. Web browsers cache previously accessed web resources and reuse them when possible to reduce network traffic. HTTP proxy servers at private network boundaries can facilitate communication for clients without a globally routable address, by relaying messages with external servers.

HTTP is an application layer protocol designed within the framework of the Internet Protocol Suite. Its definition presumes an underlying and reliable transport layer protocol, and Transmission Control Protocol (TCP) is commonly used.

However HTTP can be adapted to use unreliable protocols such as User Datagram Protocol (UDP), for example in HTTPU and Simple Service Discovery Protocol (SSDP).

HTTP resources are identified and locatedon the network by uniform resourcelocators (URLs), using the uniform resource identifier (URI) schemes http and https. URIs and hyperlinks in Hypertext Markup Language (HTML)documents form inter-linked hypertext documents.

HTTP/1.1 is a revision of the original HTTP (HTTP/1.0). In HTTP/1.0 a separate connection to the same server is made forevery resource request. HTTP/1.1 can reuse a connection multiple times to download images, scripts, stylesheets, etc. after the page has been delivered. HTTP/1.1 communications therefore experience less latency as the establishment of TCP connections presents considerable overhead.

Requestmethods

HTTP defines methods (sometimes referred to as verbs) to indicate the desired action to be performed on the identified resource. What this resource represents, whether pre-existing data or data that is generated dynamically, depends on the implementation of the server. Often, the resource corresponds to a file or the output of an executable residing onthe server. The HTTP/1.0 specification defined the GET, POST and HEAD methods and the HTTP/1.1 specification added 5 new methods: OPTIONS, PUT, DELETE, TRACE and CONNECT. By being specified in these documents their semantics are well known and can be depended on. Any client can use any method and the server can be configured to support any combination of methods. If a method is unknown to an intermediate it will be treated as an unsafe and non-idempotent method. There is no limit to the number of methods that can be defined and this allows for future methods to be specified without breaking existing infrastructure. For example, WebDAV defined 7 new methods and RFC 5789 specified the PATCH method.

-      GET: The GET method requests are presentation of the specified resource. Requests using GET should only retrieve data and should have no other effect. (This is also true of some other HTTP methods.) The W3C has published guidance principles on this distinction, saying, “Web application design should be informed by the above principles, but also by the relevant limitations”

-      HEAD: The HEAD method asks for a response identical to that of a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content.

-      POST: The POST method requests that the server accept the entity enclosed in the request as a new subordinate of the web resource identified by the URO. The data POSTed might be, for example, an annotation for existing resources; a message for a bulletin board, newsgroup, mailing list, or comment thread; a block of data that is the result of submitting a web form to a data-handling process; or an item to add to a database.

-      PUT: The PUT method requests that the enclosed entity be stored under the supplied URI. If the URI refers to an already existing resource, it is modified; if the URI does not point to an existing resource, then the server can create the resource with that URI.

 From: https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

Open System Interconnection Protocols

The Open System Interconnection (OSI)protocol suite is comprised of numerous standard protocols that are based onthe OSI reference model. These protocols are part of an international programto develop data-networking protocols and other standards that facilitate multivendorequipment interoperability. The OSI program grew out of a need forinternational networking standards and is designed to facilitate communicationbetween hardware and software systems despite differences in underlyingarchitectures.

The OSI specifications were conceived and implementedby two international standards organizations: the International Organizationfor Standardization (ISO) and the International Telecommunications StandardsSector (ITU-T). This article provides a summary of the OSI protocol suite andillustrates its mapping to the general OSI reference model.

From: http://docwiki.cisco.com/wiki/Open_System_Interconnection_Protocols

Packet-filtering

On the Internet, packet filtering is theprocess of passing or blocking packets at a network interface based on source and destination addresses, ports, or protocols. The process is used inconjunction with packet mangling and Network Address Translation (NAT). Packet filtering is often part of a firewallprogram for protecting a local network from unwanted intrusion.

In a software firewall, packet filtering isdone by a program called a packet filter. The packet filter examines the headerof each packet based on a specific set of rules, and on that basis, decides toprevent it from passing (called DROP) or allow it to pass (called ACCEPT).

There are three ways in which a packetfilter can be configured, once the set of filtering rules has been defined. Inthe first method, the filter accepts only those packets that it is certain aresafe, dropping all others. This is the most secure mode, but it can causeinconvenience if legitimate packets are inadvertently dropped. In the secondmethod, the filter drops only the packets that it is certain are unsafe,accepting all others. This mode is the least secure, but causes less inconvenience,particularly in casual Web browsing. In the third method, if the filterencounters a packet for which its rules do not provide instructions, thatpacket can be quarantined or the user can be specifically queried concerningwhat should be done with it. This can be inconvenient if it causes numerousdialog boxes to appear, for example, during Web browsing.

Packet Filtering Firewall: An Introduction

The Packet Filtering Firewall is one of themost basic firewalls. The first step in protecting internal users from theexternal network threats is to implement this type of security. The first everfirewalls used were of packet filtering type only. As the trends of networkthreats started changing, so did the firewall building strategies. Most of the routers have packet filtering built-in,but the problem with the outers is that, they are difficult to configure anddon’t provide extensive logs of the incidents.

To star with the network security, thepacket filtering firewalls are the way to go. This functionality is still themain aim of most of the commercial and non-commercial firewalls. As you know bythe definition and the purpose of the firewall, the firewall is the firstdestination for the traffic coming to your internal network. So, anything whichcomes to your internal network passes through the firewall. Of course, reverseis also true. Any outgoing traffic will also pass through the firewall beforeleaving your network completely. This is the reason that sometimes this type offirewall filter is also called screening routers.

Types of Packet Filtering

Packet filtering firewall allows only thosepackets to pass, which are allowed as per your firewall policy. Each packetpassing through is inspected and then the firewall decide to pass is or not.The packet filtering can be divided into two parts:

1.    Stateless packet filtering.

2.    Stateful packet filtering.

The data travels through the internet inthe form of packets. Each packet has a header which provides the informationabout the packet, its source and destination etc. The packet filteringfirewalls inspects these packets to allow or deny them. The information may ormay not be remembered by the firewall.

Stateless Packet Filtering

If the information about the passing is notremembered by the firewall, then this type of filtering is called statelesspacket filtering. This type of firewalls is not smart enough and can be fooledvery easily by the hackers. These are especially dangerous for UDP type of data packets. The reason isthat, the allow/deny decisions are taken on packet by packet basis and theseare not related to the previous allowed/denied packets.

StatefulPacket Filtering

If the firewall remembers the informationabout the previously passed packets, then that type of filtering is statefulpacket filtering. These can be termed as start firewalls. This type offiltering is also known as Dynamic packet filtering.

Important Features of Packet Filters

The great firewalls normally follow fewspecific rules upon which features are incorporated during firewall designing. Feware listed below:

1.    The firewall should providegood deal of logs. The more detailed are the logs, the better the protection.

2.    The command line syntax or GUIof firewall should be easy to create new rules and of course firewallexceptions.

3.    The packet filter orders shouldbe evaluated carefully in order to make the filtering fruitful.

Form: http://searchnetworking.techtarget.com/definition/packet-filtering

From: http://securityworld.worldiswelcome.com/packet-filtering-firewall-an-introduction

User Datagram Protocol

The User Datagram Protocol (UDP) is one ofthe core members of the Internet protocol suite. The protocol was designed by David P. Reed in 1980 and formally defined in RFC 768.

UDP uses a simple connectionless transmission model with a minimum of protocol mechanism. It has no handshaking dialogues, and thus exposes the user’s program to any unreliability of the underlying network protocol. There is no guarantee of delivery, ordering, or duplicate protection. UDP provides checksums for data integrity, and port numbers for addressing different functions at the source and destination of the datagram.

With UDP, computer applications can send messages, in this case referred to as datagrams, to other hosts on an Internet Protocol (IP) network without prior communications to set up special transmission channels or data paths. UDP is suitable for purposes where error checking and correction is either not necessary or is performed in the application, avoiding the overhead of such processing atthe network interface level. 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. If error correction facilities are needed atthe network interface level, an application may use the Transmission Control Protocol (TCP) or Streaming Control Transmission Protocol (SCTP) which are designed for this purpose.

Packet structure

UDP is a minimal message-oriented Transport Layer protocol that is documented in IETF RFC 768.

UDP provides no guarantees to the upper layer protocol for message delivery and the UDP layer retains no state of UDP messages once sent. For this reason, UDP sometimes is referred to as Unreliable Datagram Protocol.

UDP provides application multiplexing (via port numbers) and integrity verification (via checksum) of the header and payload. If transmission reliability is desired, it must be implemented in the user’s application.

The UDP header consists of 4 fields, each of which is 2 bytes (16 bits). The use of the fields “Checksum” and “Source port” is optional in IPv4. In IPv6 only the source port is optional.

-      Source port number: This field identifies the sender’s port when meaningful and should be assumed to be the port to reply to if needed. If not used, then it should be zero. If the source host is the client, the port number is likely to be an ephemeral port number.

-      Destination port number: This field identifies the receiver’s port and is required. Similar to source port number, if the client is the destination host then the port number will likely be an ephemeral port number and if the destination host is the server then the port number will likely be a well-known port number.

-      Length: A field that specifies the length in bytes of the UDP header and UDP data. The minimum length is 8 bytes because that is the length of the header. The field size sets a theoretical limit of 65,535 bytes (8 byte header + 65,527 bytes of data) for a UDP datagram. The practical limit for the data length which is imposed by the underlying IPv4 protocol is 65,507 bytes (65,535 – 8 byte UDP header – 20 byte IP header).

-      Checksum: The checksum field may be used for error-checking of the header and data. This field is optional in IPv4, and mandatory in IPv6. The field carries all-zeros if unused.

Reliability and congestion control solutions

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 employer liability mechanisms and may even be hindered by them. Streaming media, real-time multiplayer games and voice over IP (VoIP) are examples of applications that often use UDP. In the separticular applications, loss of packets is not usually a fatal problem. If anapplication requires a high degree of reliability, a protocol such as the Transmission Control Protocol may be used instead.

From: https://en.wikipedia.org/wiki/User_Datagram_Protocol