skip to content

With MOBIKE (RFC 4555), what happens to an IKEv2 remote-access client's SAs when the laptop moves from office Wi-Fi to a cellular network?

level: middleimportance: nice to knowfreq 9%

answer

  1. keep the SAs, change the envelope
  2. negotiated during IKE_AUTH
  3. an INFORMATIONAL from the new address
  4. UPDATE_SA_ADDRESSES and COOKIE2

basics

~20 s

With MOBIKE the client keeps its IKE SA and Child SAs: it sends an UPDATE_SA_ADDRESSES notify from the new address, the gateway checks that address, and only the outer tunnel addresses change while inner addresses and selectors stay.

solid answer

~50 s

Base IKEv2 binds the IKE SA and tunnel-mode Child SAs to the addresses used at setup, so a new address would mean a new IKE SA — possibly with the user re-entering a token code — and broken inner connections. MOBIKE, negotiated by both peers sending `MOBIKE_SUPPORTED` in `IKE_AUTH`, lets the client keep them. On the move it sends an `INFORMATIONAL` request carrying `UPDATE_SA_ADDRESSES` from its new address and starts sending ESP from there; the gateway records the address and, by default, first runs a **return routability check** — an `INFORMATIONAL` exchange with a `COOKIE2` the client must echo — before sending ESP to it. Only the outer tunnel-header addresses change; the inner address and traffic selectors stay, so applications barely notice. MOBIKE covers tunnel mode only, and the initiator decides which address pair is used.

go deeper

for a junior

Recall that MOBIKE is an IKEv2 extension that keeps a VPN connected when a client's address changes, instead of reconnecting from scratch.

for a middle

Explain the exchange: MOBIKE_SUPPORTED in IKE_AUTH, UPDATE_SA_ADDRESSES in an INFORMATIONAL from the new address, and a COOKIE2 return routability check before the gateway switches.

for a senior

Show what survives a move and what does not, why the gateway checks return routability, and the limits: tunnel mode only, initiator behind the NAT, no simultaneous movement.

for a principal

Weigh roaming support in a remote-access design: fewer re-authentications and dropped sessions, against relying on clients and gateways that both implement MOBIKE and on a stable gateway address.

## The problem MOBIKE solves In base IKEv2 (RFC 7296) the IKE SA and the tunnel-mode Child SAs are created between the IP addresses used when the IKE SA was set up, and those addresses become the **outer (tunnel header) addresses** of every ESP packet. They cannot be changed afterwards. A laptop that leaves office Wi-Fi for a cellular network gets a new address, so without an extension it must build a new IKE SA from scratch. RFC 4555 names the first two costs below; the third follows from RFC 7296, where an address assigned through the configuration payload lasts at least until the IKE SA is deleted, and no longer is promised: - re-authentication may need **user interaction**, such as typing a code from a token card; - a new IKE SA costs Diffie-Hellman computation and several round trips; - the client may receive a different inner address, breaking every connection running through the VPN. MOBIKE, the IKEv2 Mobility and Multihoming Protocol (RFC 4555, Standards Track), updates the addresses of the **existing** IKE SA and Child SAs instead. ## Agreeing to use it Both peers include a `MOBIKE_SUPPORTED` notify in the `IKE_AUTH` exchange. A gateway with several addresses may also list them in `ADDITIONAL_IP4_ADDRESS` or `ADDITIONAL_IP6_ADDRESS` notifies, or say it has no others with `NO_ADDITIONAL_ADDRESSES`. MOBIKE gives the **initiator** — the client in remote access — the job of choosing which address pair the IPsec SAs use and of detecting which pairs work; the gateway tells it what addresses exist and waits to be told. ## The move, step by step 1. The client learns from lower layers that its attachment point and address changed. 2. It sends an `INFORMATIONAL` request containing `UPDATE_SA_ADDRESSES` (plus NAT-detection notifies) **from the new address**, and starts using that address as the source of its own ESP traffic. 3. The gateway records the new address and, if its policy requires, runs a **return routability check**: it sends an `INFORMATIONAL` request carrying a `COOKIE2` notify, which the client must copy unchanged into its response. 4. When the check succeeds, the gateway starts sending ESP to the new address. The IKE SA, the Child SA keys and the user's authentication all survive; no new `IKE_SA_INIT` or `IKE_AUTH` runs. ## What changes and what does not | Item | After a MOBIKE update | |---|---| | Outer tunnel-header addresses | Changed to the new pair | | Inner address and traffic selectors | Unchanged | | IKE SA and Child SA keys | Unchanged | | NAT traversal | Enabled or disabled as the new path needs | | User authentication | Not repeated | Because the inner addresses stay, mobility is mostly invisible to applications. The UDP encapsulation used to cross a NAT is the business of NAT traversal; MOBIKE only switches it on or off as the new path requires. ## The two security checks - **Return routability.** Without it, an authenticated peer could claim someone else's address and point the gateway's ESP traffic at a third party. RFC 4555 says the check SHOULD be done by default and before the SAs are updated; it MAY be skipped where peers are well behaved, as in many corporate VPNs, or the address is vouched for another way. - **NAT prohibition.** When NAT traversal is not in use, the `NO_NATS_ALLOWED` notify lets a peer detect that a NAT or translator has rewritten addresses. ## Limits worth knowing - **Tunnel mode only**; transport-mode SAs are out of scope. - **One address pair at a time**; load balancing across interfaces is out of scope. - **No rendezvous**: if both ends move at once nothing finds them again, so at least one end — normally the gateway — needs a stable address. - **NAT asymmetry**: MOBIKE assumes the initiator is the party behind a NAT, so changes of the gateway's own address are not fully supported. - **No one-way paths**: responses go to the address and port a request came from. - **Patience at the gateway**: because the client leads recovery, RFC 4555 suggests responders keep retransmitting IKEv2 requests for at least five minutes before giving up. In an interview, the core is: outer addresses move, inner state stays, the client drives, and the gateway verifies the new address before sending traffic to it.

  • Why does MOBIKE let the client, not the gateway, choose which address pair the IPsec SAs use?
    It matches how IKEv2 already works — the initiator picks the addresses it uses to reach the responder — and the mobile client is the party that knows which of its interfaces are up and preferred. The gateway only advertises its own addresses and updates the SAs when the client tells it to.
  • Does MOBIKE help when the remote-access client is behind a NAT that changes its mapping?
    Yes, within limits. MOBIKE assumes the initiator is the party behind the NAT and can turn NAT traversal on or off as paths change, and it includes NAT-detection notifies in the address update. What it does not fully support is the gateway's own address changing while the client sits behind a restrictive NAT.

Moving house while keeping your bank account: you tell the bank your new address, and it mails a confirmation letter there before sending statements; the account number never changes.

saying these in an interview costs you the question

  • MOBIKE gives the client a new inner address on every network change.
  • Without MOBIKE, IKEv2 simply updates the peer address automatically.
  • The gateway decides which address pair the IPsec SAs use.
  • MOBIKE works for transport-mode SAs as well as tunnel mode.
  • MOBIKE renegotiates the Child SA keys whenever the address changes.