NG_MPPC(4)

πŸ’– ng_mppc β€” the Microsoft MPPC/MPPE compression + encryption netgraph node type πŸ’–

okay bestie, gather round, because this is the manual page for ng_mppc from the Kernel Interfaces Manual β€” that's section 4 of the FreeBSD manual, the "device drivers and kernel interfaces" section, iykyk. it's a netgraph node type and it is SO specific and I love that for it.


✨ SYNOPSIS ✨

#include <sys/types.h>
#include <netgraph/ng_mppc.h>

like, that's it. that's the whole vibe. include these two headers and you're in. πŸ’…


πŸ¦‹ DESCRIPTION πŸ¦‹

so the mppc node type implements the Microsoft Point-to-Point Compression (MPPC) and Microsoft Point-to-Point Encryption (MPPE) sub-protocols of the PPP protocol. no cap. and here's the tea: these protocols are often used in conjunction with the Point-to-Point Tunneling Protocol (PPTP). iconic combo honestly.

the node has two hooks: comp for compression and decomp for decompression. typically one or both of these hooks would be connected to the ng_ppp(4) node type hook of the same name. each direction of traffic flow is independent of the other β€” they don't text each other, they don't share a group chat, they just do their own thing. 🫢


πŸŽ€ HOOKS πŸŽ€

this node type supports the following hooks, bestie:

  • comp β€” connection to ng_ppp(4) comp hook. incoming frames are compressed and/or encrypted, and sent back out the same hook. it's giving "in and out, no detours". πŸ”₯
  • decomp β€” connection to ng_ppp(4) decomp hook. incoming frames are decompressed and/or decrypted, and sent back out the same hook. the mirror image, the twin flame, the other half of the story. ✨

πŸ’… CONTROL MESSAGES πŸ’…

this node type supports the generic control messages, plus the following lil' special ones:

🌸 NGM_MPPC_CONFIG_COMP

this command resets and configures the node for a session in the outgoing traffic direction (i.e., for compression and/or encryption). it takes a struct ng_mppc_config as an argument:

/* Length of MPPE key */
#define MPPE_KEY_LEN      16

/* MPPC/MPPE PPP negotiation bits */
#define MPPC_BIT          0x00000001      /* mppc compression bits */
#define MPPE_40           0x00000020      /* use 40 bit key */
#define MPPE_56           0x00000080      /* use 56 bit key */
#define MPPE_128          0x00000040      /* use 128 bit key */
#define MPPE_BITS         0x000000e0      /* mppe encryption bits */
#define MPPE_STATELESS    0x01000000      /* use stateless mode */
#define MPPC_VALID_BITS   0x010000e1      /* possibly valid bits */

/* Configuration for a session */
struct ng_mppc_config {
    u_char    enable;                 /* enable */
    uint32_t  bits;                   /* config bits */
    u_char    startkey[MPPE_KEY_LEN]; /* start key */
};

okay so let's break this down because the struct is lowkey the whole main character here:

  • the enable field enables traffic flow through the node. if it's not set, nothing's moving, periodt.
  • the bits field contains the bits as negotiated by the Compression Control Protocol (CCP) in PPP. those are the MPPC_BIT, MPPE_40, MPPE_56, MPPE_128, MPPE_STATELESS situation up there.
  • the startkey is only necessary if MPPE was negotiated, and it must be equal to the session start key as defined for MPPE. this key is based on the MS-CHAP credentials used at link authentication time. so like, remember your auth, bestie, because this key comes straight from it. πŸ”‘

🌈 NGM_MPPC_CONFIG_DECOMP

this command resets and configures the node for a session in the incoming traffic direction (i.e., for decompression and/or decryption). this command takes a struct ng_mppc_config as an argument. yes, the same struct. same energy, opposite direction. πŸ’–

⭐ NGM_MPPC_RESETREQ

this message contains no arguments, and it's bi-directional. not me being a two-way queen. πŸ‘‘

so here's what happens:

  • if an error is detected during decompression, this message is sent by the node to the originator of the NGM_MPPC_CONFIG_DECOMP message that initiated the session. the receiver should respond by sending a PPP CCP Reset-Request to the peer.
  • this message may also be received by this node type when a CCP Reset-Request is received by the local PPP entity. the node will respond by flushing its outgoing compression and encryption state so the remote side can resynchronize. like a little reset button but make it protocol. πŸ”„

🧚 SHUTDOWN 🧚

this node shuts down upon receipt of a NGM_SHUTDOWN control message, or when both hooks have been disconnected. so basically it's like "okay bye, nobody's talking to me anymore". 😭


🌟 COMPILATION 🌟

the kernel options NETGRAPH_MPPC_COMPRESSION and NETGRAPH_MPPC_ENCRYPTION are supplied to selectively compile in either or both capabilities.

⚠️ at least one of these must be defined, or else this node type is useless. like, genuinely useless. don't do that to yourself, bestie. define one. πŸ™ˆ

πŸ‘‘ SEE ALSO πŸ‘‘

  • netgraph(4), ng_ppp(4), ngctl(8)
  • G. Pall, Microsoft Point-To-Point Compression (MPPC) Protocol, RFC 2118.
  • G. S. Pall and G. Zorn, Microsoft Point-To-Point Encryption (MPPE) Protocol, draft-ietf-pppext-mppe-04.txt.
  • K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, and G. Zorn, Point-to-Point Tunneling Protocol (PPTP), RFC 2637.

πŸ’œ AUTHORS πŸ’œ

Archie Cobbs <archie@FreeBSD.org> β€” thank you king, we appreciate you. 🫢


πŸ’€ BUGS πŸ’€

okay so this is the messy part and I'm gonna say it plainly:

in PPP, encryption should be handled by the Encryption Control Protocol (ECP) rather than CCP. however, Microsoft combined both compression and encryption into their ``compression'' algorithm, which is... confusing. that's the bug note. that's it. it's giving "we put the encryption in the compression, don't ask questions". 😭


and that's the whole page, bestie! this was ng_mppc(4) from the Debian build of the manual, dated June 7, 2016. go forth and compress responsibly. mwah πŸ’–βœ¨πŸŽ€

πŸ“¦ where this page comes from