1990s.
NetWare: Introduction
NetWare provides a variety of server daemon services and support, based on the client/server architecture. A client is a station that requests services, such as file access, from a server (see Figure 2.1). Internetwork Packet Exchange (IPX) was the original NetWare protocol used to route packets through an internetwork.
Internetwork Packet Exchange
IPX is a connectionless datagram protocol, and, as such, is similar to unreliable datagram delivery offered by the Internet Protocol (discussed in Chapter 1).
Also, like IP address schemes, Novell IPX network addresses must be unique; they are represented in hexadecimal format, and consist of two parts, a network number and a node number. The IPX network number is an assigned 32-bit long number. The node number is a 48-bit long hardware or Media Access Control (MAC) address for one of the system's network interface cards (NICs). As defined in Chapter 1, the NIC manufacturer assigns the 48-bit long hardware or MAC address. An example of an IPX address is shown in Figure 2.2.
Because the host portion of an IP network address has no equivalence to a MAC address, IP nodes must use the Address Resolution Protocol (ARP) to determine the destination MAC address (see Chapter 1).
IPX Encapsulation, Format, Header Snapshots
To process upper-layer protocol information and data into frames, NetWare IPX supports several encapsulation schemes. Among the most popular encapsulation types are Novell Proprietary, 802.3, Ethernet Version 2, and Ethernet SNAP, which are defined in the following list:
Figure 2.2 IPX Address.
Novell Proprietary. Novell's initial encapsulation type, also known as Novel Ethernet 802.3
and 802.3 Raw.
802.3. The standard IEEE 802.3 format, also known as Novell 802.2.
Ethernet II. Includes a standard Ethernet Version 2 header.
Ethernet SNAP. An extension of 802.3.
IPX network numbers play a primary role in the foundation for IPX internetwork packet exchange between network segments. Every segment is assigned a unique network address to which packets are routed for node destinations. For a protocol to identify itself with IPX and communicate with the network, it must request a socket number. Socket numbers ascertain the identity of processes within a station or node. IPX formatting is shown in Figure 2.3; its fields are defined as follows:
Checksum. The default for this field is no checksum; however, it can be configurable to perform on the IPX section of the packet.
Packet Length. The total length of the IPX packet.
Transport Control. When a packet is transmitted and passes through a router, this field is incremented by 1. The limit for this field is 15 (15 hops or routers). The router that increments this field number to 16 will discard the packet.
Packet Type. Services include:
(Type 0) Unknown packet type (Type 1) Routing information packet
(Type 4) IPX packet or used by the Service Advertisement Protocol (SAP; explained in the next section)
Figure 2.3 An IPX packet.
(Type 17) NetWare core protocol packet
(Type 20) IPX NetBIOS broadcast
Destination Network. The destination network to which the destination node belongs. If the destination is local, this field is set to 0.
Destination Node. The destination node address.
Destination Socket. The destination node's process socket address.
Source Network. The source network to which the source node belongs. If the source is unknown, this field is set to 0.
Source Node. The source node address.
Source Socket. The source node's process socket address that transmits the packet.
Data. The IPX data, often including the header of a higher-level protocol.
Keeping in mind the fields in Figure 2.3, now take a look at Figure 2.4 to compare the fields an actual IPX header captures during transmission.
Service Advertisement Protocol
The Service Advertisement Protocol (SAP) is a method by which network resources, such as file servers, advertise their addresses and the services they provide. By default, these advertisements are sent every 60 seconds. A SAP identifier (hexadecimal number) indicates the provided services; for example, Type 0x0007 specifies a print server. Let's take a look at a real world scenario of SAP in Figure 2.5.
In this scenario, the print and file server will advertise SAP messages every 60 seconds. The router will listen to SAPs, then build a table of the known advertised services with their network addresses. As the router table is created, it too will be sent out (propagated) to the network every 60 seconds. If a client (Station A) sends a query and requests a particular printer process from the print server, the router will respond with the network address of the requested service. At this point, the client (Station A) will be able to contact the service directly.
Hacker's Intercepting unfiltered SAP messages as they propagate the network
SAP Format, Header Snapshots, Filters
SAP packets can contain service messages for up to seven servers. Should there be more than seven, multiple packets will be sent. Let's examine the SAP format and fields in Figure 2.6:
Operation. The type of operation: a SAP request or response.
Source Type. The type of service provided:
Type
0x0004:
File Server
Type
0x0005:
Job Server
Type
0x0007:
Print Server
Type
0x0009:
Archive Server
Type
0x000A:
Job Queue
Type
0x0021:
SNA Gateway
Type
0x002D:
Time Sync
Type
0x002E:
Dynamic SAP
Type
0x0047:
Advertising Print Server
Type
0x004B:
Btrieve VAP
Type
0X004C:
SQL VA
Type
0x0077:
Unknown
Type
0x007A:
NetWare VMS
Type
0x0098:
NetWare Access Server
Type
0x009A:
Named Pipes Server
Type
0x009E:
NetWare-UNIX
Type
0x0107:
NetWare 386
Type
0x0111:
Test Server
Type
0x0166:
NetWare Management
Type
0x026A:
NetWare Management
Service. Contains the unique name of the server.
Network Address. The server's network address.
Node Address. The node's network address.
Socket Address. Server request and response socket numbers.
• Hops. The number of routers or gateways between the client and server.
Now that you have a grasp on SAP operation and its associated header format, let's compare the fields in Figure 2.6 with real-world captures (during transmission) of SAP headers shown in Figure
2.7.
To conserve network throughput and avoid SAP flooding, SAPs can be filtered on a router or gateway's interfaces. In medium to large networks, with hundreds and sometimes thousands of advertised services, SAP filtering to specific routers is sometimes mandatory. It is recommended to employ SAP filters for services that are not required for a particular network; for example, remote sites in most cases do not require SAP advertising for printer services at another remote site.
NetWare General Service Response
SAP
SAP
Service type = 03FD (Intel NetPortExpress XL)
SAP
Server name - "XER0X_nl_71"
SAP
Network = O0B71k01. Node = J0AAQ05E136A,
Socket
E48Q
CAP
Intermediate networks ■ 5
SAP
SAP
Service type = 030C (HP LaserJet)
SAP
Server name = "O0irj831C2OC5 8 3DANPIlC2OC5
ii
SAP
Network - QCBS9321, Node - rjQ10B31C20C5.
Socket
400C
SAP
Intermediate networks ■ Ј
SAP
SAP
Service type ■ 0077 (Unknown service)
SAP
Server name = "TS@BR SERVER 59"
SAP
Network ■ 0CC59321, Node - 000000000001,
Socket
cooo
SAP
Intermediate networks = 7
SAP
SAP
Service type = 04 4C (ARCserver 5.0)
SAF
Server name = ,,iRS0214 3 0fcBR_SERVER_59-
SAP
Hetwork = 0QC59321, Node - 000000000001.
■z Dcke:
8600
SAP
Intermediate networks = 7
SAP
SAP
Service type = 004B (Btrieve VAP 5.x)
SAP
Server name - "6SER4.00-6.1Q_00CS93210000000000010000"
SAP
Network = O0C59321. Node = QO000OO000O1,
Socket
=
8059
SAF
Intermediate networks = 7
SAP
SAP
Service ty^e = HO7 (Netware 386)
SAP
Server name = "ER_SERVER_59"
SAP
Network = O0C59321, Node = OOCOQOOOOOOl.
Socket
=
8104
SAP
Intermediate networks ■ 7
Figure 2.7 SAP header sniffer capture.
Hackers who can penetrate a router or gateway can bring medium to large networks down by removing or modifying SAP filters. So-called SAP flooding is a common issue when analyzing bandwidth degradation in a Novell environment.
Sequenced Packet Exchange
The most common NetWare transport protocol is the Sequenced Packet Exchange (SPX). It transmits on top of IPX. Like TCP, SPX provides reliable delivery service, which supplements the datagram service in IPX. For Internet access, Novell utilizes IPX datagrams encapsulated in UDP (which is encapsulated in IP) for transmission. SPX is a packet-oriented protocol that uses a transmission window size of one packet. Applications that generally use SPX include R-Console and P-Console. We'll talk more about these applications later in this book.
SPX Format, Header Snapshots
The SPX header contains sequencing, addressing, control, and acknowledgment information (see Figure 2.8). Its fields are defined as follows:
Connection Control. Controls the bidirectional flow of data.
Data Stream Type. Type of data in the packet:
Figure 2.8 An SPX packet.
Source Connection ID. IPX-assigned connection ID number, at the source, during connection establishment. Used for demultiplexing (refer to Chapter 1).
Destination Connection ID. IPX-assigned connection ID number, at the destination, during connection establishment. During the connection establishment request, this field is set to 0xffff. It is used for demultiplexing (refer to Chapter 1).
Sequence Number. The sequence number of the most recently sent packet. Counts packets exchanged in a direction during transmission.
Acknowledgment Number. Specifies the next packet's sequence number. Used for reliable delivery service.
Allocation Number. Specifies the largest sequence number that can be sent to control outstanding unacknowledged packets.
After reviewing the SPX header format, let's compare these findings to actual captures during transmission, as shown in Figure 2.9.
Connection Management, Session Termination
Remember the reliable delivery connection establishment in Chapter 1? SPX uses the same type of methodology, whereby connection endpoints verify the delivery of each packet. During connection establishment, an SPX connection request must take place. This is somewhat similar to the three-way-handshake discussed in Chapter 1. These connection management packets incorporate the following sequence:
Connection request.
Connection request ACK.
Informed Disconnect.
Informed Disconnect ACK.
Using this connectivity, SPX becomes a connection-oriented service, with guaranteed delivery and tracking. Note that, in addition to Informed Disconnect, there is another method of session called the Unilateral Abort; it is used for emergency termination.
Watchdog Algorithm
After a NetWare client logs in to a NetWare server and begins sending requests, the server uses the Watchdog process to monitor the client's connec- tion. If the server does not receive any requests from the client within the Watchdog timeout period, the server will send a Watchdog packet to that client. A Watchdog packet is simply an IPX packet that contains a connection number and a question mark (?) in the data portion of the packet. If the client's communications are still active, the client responds with a Y, indicating that the connection is valid. The watchdog algorithm is technology that
39 allows SPX to passively send watchdog packets when no transmission occurs during a session. Basically, a watchdog request packet, consisting of an SPX header with SYS and ACK bits set, is sent. The receiving station must respond with a watchdog acknowledgment packet to verify connectivity. If the watchdog algorithm has repeatedly sent request packets (approximately 10 for 30 seconds) without receiving acknowledgments, an assumption is made that the receiving station is unreachable, and a unilateral abort is rendered.
Figure 2.9 SPX header sniffer capture. Error Recovery, Congestion Control
Advancements in SPX technologies took error recovery from an error detection abort to packet retries and windowing. If the receiving station does not acknowledge a packet, the sending station must retry the packet submission. If the sending station still does not receive an acknowledgment, the sender must find another route to the destination or receiving station and start again. If acknowledgments fail again during this process, the connection is canceled with a unilateral abort.
To avoid contributing to bandwidth congestion during attempted transmissions, SPX will not submit a new packet until an acknowledgment for the previous packet has been received. If the acknowledgment is delayed or lost because of degradation, SPX will avoid flooding the network using this simple form of congestion control.
Wrapping Up
In spite of technological embellishments, millions of networks still incorporate NetWare IXP/SPX as primary communication protocols. Additionally, corporate network segments, small office and home office networks (SOHOs) still utilize NetBIOS. Many proprietary communication suites such as wireless LAN modules and bar coding packages depend on NetBIOS to boot. With that in mind, let's move on to discuss this age-old protocol.
Seen strictly as a LAN protocol, NetBIOS is limited, as it is not a routable protocol. For this reason, NetBIOS must be bridged or switched to communicate with other networks. Utilizing broadcast frames as a transport method for most of its functionality, NetBIOS can congest wide area network (WAN) links considerably.
NetBIOS relies on broadcast frames for communication, and as such, can congest WAN links and become vulnerable for passive s niffing.
NetBIOS Session protocol
NETS:
NETB: Type = 81 (Session request)
NETB: Flags = 00
NETB: Totaf session packet length = 68
NETS: Called NetBIOS name = SHERATON3<20>
NETB: Calling NetBIOS name = ANDERSON SHERRY<00>
In this snapshot we witness a session request and a resolution for the NetBIOS station's, individual name.
■- NetBIOS Session protocol
Type = 00 (Session request) Flags = 00
Total session packet length = 4096
This snapshot is an example of NetBIOS data transfer after the name resolution and session request above.
Figure 2.10 NetBIOS header sniffer capture. Naming Convention, Header Snapshots
NetBIOS names contain 16 characters (see Figure 2.10 for a header capture example) and consist of two different types:
Group Names. A unique group of stations.
Individual Name. A unique NetBIOS station or server.
In order to communicate with other NetBIOS stations, a NetBIOS station must resolve its own name; it can have multiple individuals or group names (see Figure 2.11 for a real-world NetBIOS naming scenario).
General, Naming, Session, and Datagram Services
To communicate across the network, a station's applications can request many different types of NetBIOS services, including:
GENERAL SERVICES
Reset. Used to free up resources into the NetBIOS pool for use by other applications.
Status. Includes sending/receiving station NIC status.
Cancel. Used to cancel a command.
Alert. Issued to turn on NIC soft error notification for a specified time.
Unlink. Backward compatibility.
NAMING SERVICES
Add Name. Used to add a name to NetBIOS.
Add Group. Used to add a group to NetBIOS.
Delete Name. Used to delete names and groups.
Find Name. Used to search for a name or group.
SESSION SERVICES
Basically, establishes and maintains a communication session between NetBIOS stations based on user-assigned or NetBIOS-created names.
DATAGRAM SERVICES
Used when NetBIOS wants to send transmissions without a required response with datagram frames. This process frees an application from obtaining a session by leaving the transmission up to the NIC. Not only is this process an unreliable delivery service, but it also is limited in data size: Datagrams will allow only up to 512 bytes per transmission. Datagram service commands include:
Send Datagram.
Used for datagram delivery to any name or group on the network.
Send Broadcast Datagram.
Any station with an outstanding Receive Broadcast Datagram will receive the broadcast datagram upon execution of this command.
Receive Datagram.
Receive Broadcast. Datagram.
A station will receive a datagram from any station that issued a Send Datagram command.
A station will receive a datagram from any station that issued a Send Broadcast Datagram command.
NetBEUI: Introduction
The primary extended functions of NetBIOS are part of the NetBIOS Extended User Interface, or NetBEUI, technology. Basically, NetBEUI is a derivative of NetBIOS that utilizes NetBIOS addresses and ports for upper-layer communications. NetBEUI is an unreliable protocol, limited in scalability, used in local Windows NT, LAN Manager, and IBM LAN server networks for file and print services. The technology offers a small, efficient, optimized stack. Due to its simplicity, vendors recommend NetBEUI for small departmental-sized networks with fewer than 200 clients.
NetBIOS Relationship
Connectionless traffic generated by NetBIOS utilizes NetBEUI as the transmission process. For example, when a station issues a NetBIOS command, whether it is Add Name or Add Group, it is NetBEUI that sends out frames to verify whether the name is already in use on the network. Another example of the NetBIOS-NetBEUI relationship is the execution of the Net Use command. When the command is issued, NetBEUI locates the server using identification frames and commences the link establishment.
Windows and Timers
Recall the sliding window technology described in Chapter 1. Comparable to the TCP windowing process, NetBEUI utilizes a sliding window algorithm for performance optimization, while reducing bandwidth degradation. For traffic regulation, NetBEUI uses three timers, T1, T2, and Ti:
Response Timer (T1). Time to live before a sender assumes a frame is lost. The value is usually determined by the speed of the link.
Acknowledgment Timer (T2). When traffic does not permit the transmission of an acknowledgment to a response frame, the acknowledgment timer starts before an ACK is sent.
Inactivity Timer (Ti). By default, a three-second timer used to specify whether a link is down. When this time has been exceeded, a response frame is generated again to wait for an acknowledgment to verify the link status.
Conclusion
At this point, we discussed various common network protocols and their relationships with network communications. Together, we investigated technical internetworking with the TCP/IP suite, IPX/SPX through to NetBIOS. Considering these protocols, let's move on to discuss the underlying communication mediums used to transmit and connect them.
No comments:
Post a Comment