PPP Suite

BSDRFC1977 http://www.cis.ohio-state.edu/htbin/rfc/rfc1977.html

BSD is the freely and widely distributed UNIX compress command source. It provides the following features:

  • Dynamic table clearing when compression becomes less effective.
  • Automatic turning off of compression when the overall result is not smaller than the input.
  • Dynamic choice of code width within predetermined limits.
  • Heavily used for many years in networks, on modem and other point-to-point links to transfer netnews.
  • An effective code width requires less than 64KBytes of memory on both sender and receive.

Before any BSD Compress packets may be communicated, PPP must reach the Network-Layer Protocol phase, and the CCP Control Protocol must reach the Opened state.

Exactly one BSD Compress datagram is encapsulated in the PPP Information field, where the PPP Protocol field contains 0xFD or 0xFB. 0xFD is used when the PPP multilink protocol is not used or “above” multilink. 0xFB is used “below” multilink, to compress independently on individual links of a multilink bundle. The maximum length of the BSD Compress datagram transmitted over a PPP link is the same as the maximum length of the Information field of a PPP encapsulated packet. Only packets with PPP Protocol numbers in the range 0x0000 to 0x3FFF and neither 0xFD nor 0xFB are compressed. Other PPP packets are always sent uncompressed. Control packets are infrequent and should not be compressed for robustness.

Structure of the BSD compress packet is as shown below:

PPP Protocol

Sequence

Data

2 bytes

2 bytes

variable

PPP Protocol When the BSD Compress compression protocol is successfully negotiated by the PPP Compression Control Protocol (CCP), the value of the protocol field is 0xFD or 0xFB. This value may be compressed when Protocol-Field-Compression is negotiated.

Sequence The sequence number, sent most significant octet first. It starts at 0 when the dictionary is cleared, and is incremented by 1 after each packet, including uncompressed packets.

The sequence number ensures that lost or out of order packets do not cause the compression databases of the peers to become unsynchronized. When an unexpected sequence number is encountered, the dictionaries must be resynchronized with a CCP Reset-Request or Configure-Request. The packet sequence number can be checked before a compressed packet is decoded.

Data The compressed PPP encapsulated packet, consisting of the Protocol and Data fields of the original, uncompressed packet. The Protocol field compression must be applied to the protocol field in the original packet before the sequence number is computed or the entire packet is compressed, regardless of whether the PPP protocol field compression has been negotiated. Thus, if the original protocol number was less than 0x100, it must be compressed to a single byte.

Interested in more details about testing this protocol? click here

DESE RFC1969 http://www.cis.ohio-state.edu/htbin/rfc/rfc1969.html

The DES encryption algorithm is a well studied, understood and widely implemented encryption algorithm which was designed for efficient implementation in hardware. The DES Encryption Protocol in an option of ECP which indicates that the issuing implementation is offering to employ the DES encryption for decrypting communications on the link, and may be thought of as a request for its peer to encrypt packets in this manner.

The ECP DESE Configuration Option has the following fields, which are transmitted from left to right:

Type

Length

Initial Nonce

 1 byte  1 byte variable

Type 1, to indicate the DECE protocol.

Length 10.

Initial Nonce 8 byte field, used by the peer implementation to encrypt the first packet transmitted after the sender reaches the opened state. To guard against replay attacks, the implementation should offer a different value during each ECP negotiation. An example might be to use the number of seconds since Jan 1st, 1970 (GMT/UT) in the upper 32 bits, and the current number of nanoseconds relative to the last second mark in the lower 32 bits.

DESE packets have the following format:

Address

Control

0000

Protocol ID

Sequence number high

Sequence number low

Cyphertext (variable length)

1 byte

 1 byte 1 byte 1 byte

Protocol ID The value of this field is 0x53 or 0x55; the latter indicates that ciphertext includes headers for the Multilink Protocol, and requires that the Individual Link Encryption Control Protocol has reached the opened state. The leading zero may be absent if the PPP Protocol Field Compression option (PFC) has been negotiated.

Sequence number 16-bit numbers which are assigned by the encryptor sequentially starting with 0 (for the first packet transmitted once ECP has reached the opened state).

Cyphertext Generation of encrypted data is described in the DESE standard.

Interested in more details about testing this protocol? click here   LZS ftp://ftp.rfc-editor.org/in-notes/rfc1974.txt. The Stac LZS data compression is used for compressing PPP encapsulated packets. The LZS algorithm is optimized to compress all file types as efficiently as possible. Even string matches as short as two octets are effectively compressed. The Stac LZS compression algorithm supports both single compression history communication and multiple compression history communication. A single compression history requires the minimum amount of memory to implement, but may not provide as much compression as a multiple history implementation. Often, many streams of information are interleaved over the same link. Each virtual link will transmit data that is independent of other virtual links. Using multiple compression histories can improve the compression ratio of a communication link by associating separate compression histories with separate virtual links of communication. The header structure is as follows:
0
1
2
3
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
6
7
8
9
0
1
PPP Protocol
(History Number)
(Check Value)
Compressed Data . . .
PPP Protocol A 2 octet field described in the Point- to-Point Protocol Encapsulation. When the Stac LZS compression protocol is successfully negotiated by the PPP Compression Control Protocol, the value is 00FD hex or 00FB hex 2. History Number The number of the compression history used. Check Value Is comprised of the LCB, or the CRC or the Sequence number as follows:
  • Either a simple one octet Longitudinal Check Byte (LCB) MAY be used, after successful negotiation of the LCB option. The LCB is the Exclusive-OR of FF(hex) and each octet of the uncompressed datagram (prior to the compression operation)
  • Or a two octet Cyclic Redundancy Check (CRC) MAY be used, instead of the LCB, after successful negotiation of the CRC option.
  • OR A one octet Sequence Number MAY be used, instead of a LCB or CRC, after successful negotiation of the Sequence Number option
Compressed Data Contains one datagram in compressed form. Interested in more details about testing this protocol? click here   MultiPPP RFC1717 ftp://ftp.rfc-editor.org/in-notes/rfc1717.txt RFC1990 http://www.cis.ohio-state.edu/htbin/rfc/rfc1990.html PPP MultiLink protocol is based on an LCP option negotiation that permits a system to indicate to its peer that it is capable of combining multiple physical links into a “bundle”. Multilink is negotiated during the initial LCP option negotiation. A system indicates to its peer that it is willing to do multilink by sending the multilink option as part of the initial LCP option negotiation. This negotiation indicates three things:
  1. The system offering the option can combine multiple physical links into one logical link;
  2. The system can receive upper layer protocol data units (PDU) fragmented using the multilink header (described later) and reassemble the fragments back into the original PDU for processing;
  3. The system is capable of receiving PDUs of size N octets where N is specified as part of the option even if N is larger than the maximum receive unit (MRU) for a single physical link.

Once multilink has been successfully negotiated, the sending system is free to send PDUs encapsulated and/or fragmented with the multilink header. To establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure the data link during Link Establishment phase. After the link has been established, there is an Authentication phase in which the Authentication protocols can be used to determine identifiers associated with each system connected by the link.

Mulitlink should coordinate multiple independent links between a fixed pair of systems, providing a virtual link with greater bandwidth than any of the constituent members. The aggregate link, or bundle, is named by the pair of identifiers for two systems connected by the multiple links. A system identifier may include information provided by PPP Authentication and information provided by LCP negotiation. The bundled links can be different physical links, as in multiple async lines, but may also be instances of multiplexed links, such as ISDN, X.25 or Frame Relay. The links can be of different kinds, such as pairing dialup async links with leased synchronous links. Multilink operation should be moduled as a virtual PPP link-layer entity where packets received over different physical link-layer entities are identified as belonging to a separate PPP network protocol (the Multilink Protocol, or MP) and recombined and sequenced according to information present in a multilink fragmentation header. All packets received over links identified as belonging to the multilink arrangement are presented to the same network-layer protocol processing machine, whether they have multilink headers or not. The packets to be transmitted using the multilink procedure are encapsulated according to the rules for PPP with the following options manually configured:
  • No async control character Map
  • No Magic Number
  • No Link Quality Monitoring
  • Address and Control Field Compression
  • Protocol Field Compression
  • No Compound Frames
  • No Self-Describing-Padding

Individual links can have different settings for these options.

Network Protocol packets are first encapsulated (but not framed) according to normal PPP procedures, and large packets are broken up into multiple segments sized appropriately for the multiple physical links. A new PPP header consisting of the Multilink Protocol Identifier, and the Multilink header is inserted before each section. (Thus the first fragment of a multilink packet in PPP will have two headers, one for the fragment, followed by the header for the packet itself). The header can either be in Long Sequence Number Fragment format or Short Sequence Number Fragment Format. The structure of the header is as follows:
PPP Header:
Address 0Xff
Control 0X03
PID(H) 0X00
PID(L) 0X3d
MP Header:
B
E
0
0
0
0
0
0
Sequence Number
Sequence Number (L)
Fragmant Data . . .
PPP FCS:
FCS
Long Sequence Number Fragment Format
 
PPP Header:
Address 0Xff
Control 0X03
PID(H) 0X00
PID(L) 0X3d
MP Header:
B
E
0
0
Sequence Number
Fragmant Data . . .
PPP FCS:
FCS
Long Sequence Number Fragment Format

Address, Control Compressed fields for the Address, the control field and the Protocol ID. PID (L), PID (H) Protocol Identififer for PPP MultiLink, this is0x00-0x3d B(egining) Bit One bit field set to 1 on the first fragment derived from a PPP packet and set to 0 for all other fragments from the same PPP packet.

E(nd) Bit A one bit field set to 1 on the last fragment and set to 0 for all other fragments. 00 Reserved field with the value of 0 Sequence Number The sequence field is a 24 bit or 12 bit number that is incremented for every fragment transmitted. Fragment Data The data itself. FCS The FCS field is inherited from the normal framing mechanism from the member link on which the packet is transmitted.

Interested in more details about testing this protocol? click here

1 2 3 4 5

PPP Family Protocol Information ATCP | BACP | BAP | BCP | BSD | BVCP | CCP | CHAP | DESE | DNCP | ECP | IPCP | IPHC | IPv6CP | IPXCP | L2F | L2TP | LCP | LQR | LZS | MPPC | MultiPPP | NBFCP | OSINLCP | PAP | PPP | PPP-BPDU | PPTP | SDCP | SNACP
Additional Information