skip to content

How does RIPv2 authenticate an update message, and why did RFC 4822's cryptographic authentication replace the original plain-text password?

level: middleimportance: nice to knowfreq 10%

answer

  1. no spare room in the header
  2. the first entry is sacrificed
  3. Address Family Identifier 0xFFFF
  4. type 2 sends the secret itself
  5. keyed hash, key ID, sequence number

basics

~20 s

RIPv2 spends the first route entry on authentication, marked by Address Family Identifier 0xFFFF. RFC 2453's only type sends a plain-text password that anyone on the link can capture; RFC 4822 sends a keyed hash with a key ID and a sequence number instead.

solid answer

~50 s

The RIP header has only two spare octets, so RFC 2453 uses a whole 20-octet entry: if the first entry's Address Family Identifier is `0xFFFF`, it carries authentication, leaving room for 24 routes. RFC 2453 defines one type, **simple password** (type 2): 16 octets of plain text. Anyone who captures one update learns the password and can inject routes, so it only guards against misconfiguration. RFC 2082 added **Keyed-MD5** (type 3); **RFC 4822** obsoletes it, keeps Keyed-MD5 and adds HMAC-SHA-1, -256, -384 and -512. A type-3 entry carries the packet length, an 8-bit `Key ID`, the authentication data length and a 32-bit non-decreasing `Sequence Number`; the hash goes in a trailer after the routes. The key ID selects the interface's security association, which allows key rollover, and the sequence number narrows replay. There is no confidentiality: routes stay readable.

go deeper

for a junior

Recall that RIPv1 has no authentication, that RIPv2 can authenticate, and that the plain-text password type sends the secret on the wire.

for a middle

Explain how the first entry with AFI 0xFFFF carries authentication, why that costs one route slot, and what the type-3 fields (Key ID, sequence number, trailer) do.

for a senior

Judge the protection: cleartext type 2 is configuration hygiene only, RFC 4822 HMAC-SHA resists forgery, replay is narrowed but not closed, and RIPv1 must be ignored to stop unauthenticated leakage.

for a principal

Weigh manual keys and per-interface associations against automated key management, and decide whether RIP belongs on links where forged updates are a realistic threat at all.

## Where authentication lives in a RIPv2 message **RIPv1** (RFC 1058) has no authentication at all. When **RIPv2** (RFC 2453) added it, there was no room in the header: authentication is a per-message function, and the header has only one 2-octet unused field. So RFC 2453 spends an **entire 20-octet route entry** on it: - If the **first** entry's **Address Family Identifier (AFI)** is `0xFFFF`, the rest of that entry is authentication, and only the first entry may be used this way. - That leaves room for **at most 24** route entries in the message instead of 25. - The entry holds a 2-octet **Authentication Type** and 16 octets of authentication data. - If authentication is not in use, no entry may carry AFI `0xFFFF`. ## Type 2: simple password, and why it fails RFC 2453 defines exactly one Authentication Type, **simple password**, type `2`: the 16 octets carry the password in **plain text**, padded with nulls. That stops a router with the wrong configuration from joining by accident, but it is no defence against an attacker: 1. Updates are sent on every RIP interface over and over, so the password is on the wire constantly. 2. Anyone who can capture one update on the link reads the password. 3. With it, they can send their own correctly authenticated updates and inject false routes. RFC 4822 describes cleartext passwords as vulnerable to easily deployed passive attacks and of no help from a security perspective. ## Type 3: cryptographic authentication, from RFC 2082 to RFC 4822 **RFC 2082** introduced **Keyed-MD5** under Authentication Type `3`. **RFC 4822** (February 2007, Standards Track) **obsoletes RFC 2082** and updates RFC 2453. It keeps Keyed-MD5 for compatibility and adds the **HMAC** construction with **SHA-1, SHA-256, SHA-384 and SHA-512**. The secret key never crosses the network; only a keyed hash does. The 16 octets that held the password now describe the hash: | Field | Size | Purpose | |---|---|---| | RIPv2 Packet Length | 16 bits | offset from the RIPv2 header to the end of the routes, i.e. where the trailer starts | | Key ID | 8 bits | with the receiving interface, selects the **RIPv2 Security Association** (key and algorithm) | | Auth Data Len | 8 bits | length of the trailing authentication data | | Sequence Number | 32 bits | non-decreasing per sender and Key ID | The hash itself travels in an **authentication trailer** after the last route entry, introduced by another `0xFFFF` marker. With HMAC-SHA-1 it is 20 octets. ## How a receiver checks a message RFC 4822 section 2.3.2 gives the order: 1. Set the received authentication data aside. 2. Find the security association from the **Key ID** and the receiving interface; if none is valid, stop and log a security event. 3. Compute the authentication data with that association's key and algorithm. 4. If it does not match, **discard** the message and log a security event. 5. If the neighbour has been heard recently and the **sequence number is lower** than the last one received, discard the message. 6. Otherwise strip the trailer and process the routes normally, recording the new sequence number. Because a security association is tied to an interface and identified by its Key ID, a router can hold several valid associations with overlapping lifetimes, which is how keys are **rolled over** without an outage. ## Limits worth stating in an interview - **Replay is narrowed, not eliminated.** The sequence number must not decrease, so an old message is rejected once the number has advanced, but RFC 4822 notes a message can be replayed until the sequence number changes, and a router that forgets its sequence number must restart from zero, a small window RFC 4822 narrows by asking for non-volatile storage of that state. - **No confidentiality.** Routes stay in the clear; RFC 4822 argues a routing protocol does not normally need secrecy. - **Manual keys.** RFC 4822's IESG note urges automated key management, which RIPv2 does not have. - **RIPv1 is not stopped.** A RIPv1 router ignores an entry whose AFI is not IP, so it still reads authenticated RIPv2 broadcasts. RFC 2453 section 5.2 accepts RIPv1 messages even when authentication is configured, but says that for maximum security they should be ignored; otherwise routes from authenticated messages leak onward unauthenticated through RIPv1 routers. ## The contrast with RIPng RIPng for IPv6 (RFC 2080) has no authentication entry at all; it relies on IPsec's Authentication Header and Encapsulating Security Payload instead. That keeps the protocol simpler but moves the work into IPsec configuration.

  • How does RFC 2453 treat RIPv1 messages and unauthenticated RIPv2 messages on a router configured for authentication?
    Unauthenticated RIPv2 messages and those that fail the check are discarded, but RIPv1 messages are still accepted. RFC 2453 adds that for maximum security RIPv1 messages should be ignored when authentication is in use; otherwise RIPv1 routers can pass on routes learned from authenticated messages without any authentication.
  • Why does the RFC 4822 sequence number not fully stop replay?
    It only has to be non-decreasing, so a captured message can be replayed until the sender's number moves on. A router that loses its sequence state must restart at zero, and the receiver should accept zero after losing contact with that neighbour, which leaves a small window. RFC 4822 asks both sides to keep that state in non-volatile storage to narrow it.
  • What does a Key ID buy an operator?
    Key rollover. The Key ID, together with the interface, names a security association holding the key and algorithm. Several associations can be valid at once with overlapping lifetimes, so routers can start sending under a new key while still accepting the old one, and legitimate updates are not lost while keys change.

saying these in an interview costs you the question

  • RIPv2 simple password authentication hashes the password before sending it.
  • RIPv2 authentication encrypts the routes so others on the link cannot read them.
  • RFC 2082's Keyed-MD5 is still the current RIPv2 authentication specification.
  • Turning on RIPv2 authentication stops RIPv1 routers from reading the updates.
  • RIPv2 authentication sits in a field of every route entry.