PPP Suite

BSD

RFC1977 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
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?

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
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:

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?

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:

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?

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:

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.

Enlarge	More Details

Interested in more details about testing this protocol?

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