Summary
- RFC 2356 proposed that a SKIP firewall identify a roaming Mobile IP node by an NSID/MKID key selector rather than treating its temporary care-of address as its identity.
- The proposal could relay the first authenticated packet without a preliminary handshake, but it still depended on trusted public components, an explicit nomadic ACL, a current binding and correctly directed Mobile IP traversal.
The awkward packet was not the one coming home. It was the one whose home address could no longer describe where it had come from.
Mobile IP, as specified in RFC 2002, gave a mobile node two addresses with different jobs. Its home address remained stable. A care-of address described its current point of attachment. That distinction allowed a home agent to intercept traffic and forward it toward the node. It also collided with a private network's firewall. A packet emitted from the public Internet with an internal source or destination could be unroutable, implausible or forbidden. A source-address rule could not recognize the same authorized machine after every move.
Published in June 1998 as an Informational document, RFC 2356 described a Sun Microsystems design for that boundary. It was not an Internet Standard and it was not a general history of virtual private networking. Its narrower problem was a node belonging to a protected private network, temporarily attached to the public Internet with a co-located care-of address, and trying to communicate across the firewall with its home agent or an internal correspondent.
The proposal compared SOCKS 5 application relaying with a packet-level approach built on SKIP, the Simple Key-management for Internet Protocols. Its attraction was timing. SKIP was described as session-less: authentication material could accompany each packet, so a firewall did not need a separate session-establishment round trip before acting on the first authenticated packet. That did not mean trust appeared from nothing. The mobile node, firewall and home agent still needed authenticated Diffie-Hellman public components, configured in advance or obtained through certificate discovery.
“First packet” described the data path, not the absence of prior trust material.
The critical mechanism was identity indirection. A conventional secure-IP lookup often began with source and destination addresses. RFC 2356 instead used a SKIP header carrying a namespace identifier, NSID, and a master-key identifier, MKID. Under NSID 1, the MKID could name the mobile node by its stable home address even while the outer packet exposed a changing care-of address. Under NSID 8, the identifier could derive from an Unsigned Diffie-Hellman public component. Names still had to be communicated securely when no certification authority vouched for them.
This made possible a nomadic access-control-list entry. Rather than authorize a fixed source address, the firewall considered packets from any address when they presented a specified key identity. “Considered” is the important word. The incoming packet still had to authenticate, historically through AH or a suitable ESP transform. The ACL still had to permit the requested communication. A valid key selector was not a universal pass into the private network.
Once an authenticated mobile node initiated contact, the firewall could bind three facts: the key identity, the permanent home address and the currently observed care-of address. That dynamic binding told the firewall where to protect and send return traffic. It also revealed the design's limit. The simple form remembered the last Registration Request. A new care-of association replaced the earlier one; simultaneous Mobile IP bindings were not supported unless the firewall understood registration messages more deeply.
State created a path dependency. A firewall that learned the binding from an outbound request expected the Registration Reply to leave through the same firewall. If several firewalls guarded the private network, asymmetric return traffic could miss the state. A Mobile-IP-aware firewall could recover more of the needed identity from the reply and reduce that constraint, but doing so moved more protocol interpretation into the boundary device.
Before any of this, someone had to decide whether the node was inside or outside. RFC 2356 allowed address-range rules, yet admitted that real installations made the classification difficult. It even treated direct human input as useful: the person holding the machine might know that the present attachment was external when the address alone was ambiguous. That is an unusually candid admission for a packet design. Location was partly a policy judgement, not a property proved by an IP prefix.
The home agent had less direct evidence. A Traversal Extension in Mobile IP Registration Requests and Replies carried addresses of points that traffic should cross. It could describe mobile-node-to-home-agent and home-agent-to-mobile-node paths, and could name more than one firewall. Some values received in the opposite direction were hints. The extension said where traversal might be required. It did not prove that authentication succeeded, a relay ran, or an internal application responded.
The RFC then separated channel arrangements that are often compressed into the word “secure.” Encryption could cover only the public side. It could run end to end, leaving the firewall as a relay while the home agent authenticated. The firewall could authenticate an end-to-end encrypted channel by receiving a long-term shared secret. Or separate encrypted associations could terminate at the firewall, allowing it to inspect traffic before starting another protected channel inside. A distinct tunnel could restore confidentiality from the firewall. Encryption, inspection authority and endpoint identity were choices, not synonyms.
Return traffic completed the design. The home agent intercepted packets addressed to the stable home address, encapsulated them toward the current care-of address and directed them through the firewall. The firewall used its dynamic binding to protect the public-side packet for the mobile node. RFC 2003 IP-in-IP encapsulation could carry cleartext traffic on an internal leg where encryption was unnecessary. Encapsulation made an address routable across a boundary; authentication established who sent protected state; encryption controlled disclosure. None established the next receipt automatically.
The security section delivered the proposal's hardest consequence. A roaming machine became an extension of the private perimeter. It might still need unencrypted public exchanges for DHCP or billing, so it required its own filtering capability. If compromised, it could offer an authenticated route into the private network. A stable cryptographic identity solved the false-negative problem of a moving address, but it could magnify the authority of a captured endpoint.
RFC 2356 therefore matters less as a preserved deployment recipe than as an early ledger for mobile trust. Outer source observed. Stable key selected. Public component obtained. Packet authenticated. ACL evaluated. Binding updated. Traversal directed. Registration answered. Packet relayed. Correspondent reached. Application completed. Every line can fail while the previous one remains true.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance

