1 / 12

Registration Revocation in Mobile IP

Registration Revocation in Mobile IP. draft-glass-mobileip-reg-revok-00.txt (soon to be -01!) Steven M. Glass - Sun Microsystems Steven.Glass@Sun.com. Why the Need?. RFC2002, etc. was designed when access was the issue. Mobile IP's focus was on functionality.

anthony-stark
Download Presentation

Registration Revocation in Mobile IP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Registration Revocationin Mobile IP draft-glass-mobileip-reg-revok-00.txt (soon to be -01!) Steven M. Glass - Sun Microsystems Steven.Glass@Sun.com

  2. Why the Need? • RFC2002, etc. was designed when access was the issue. Mobile IP's focus was on functionality. • No real-world example existed to revok a registration. At the time, short registration lifetimes were sufficient for WG consensus. • Now, AAA is [one of] the "killer apps" here. • AAA requires the possibility that a registration can be immediately terminated, and Mobile IP services suspended for a particular mobile node.

  3. Problem Space • Terminations must be able to be originated by either side - home or foreign domains. • Currently there is no "signaling" message to do this. • Terminations must be [able to be] relayed to the revoked MN (policy issue). • It MUST be understood by ALL mobile nodes, not just those "enhanced" based on this draft. • => This must be a server-only solution! • Termination messages must be Authenticated! • SAs MUST exist between HA and FA. (AAA)

  4. An Easy Solution? • 2002: MN notification mechanism already exists! • Compliant MNs understand FA becon sequence number reset means current registration is gone! • Already provide for unicast becons to MNs. Today, triggered from Agent Solicitation messages, however: • Mobile Nodes MUST support Agent Solicitations • Mobile Nodes MUST process received Agent Advertisements • Not prohibited by RFC1256 (router discovery) • Already used by [an]other MIP draft, but let's not split hairs... • If revok-becon isn't from current FA it will be ignored, so no increased risk for denial-of-service attack.

  5. Mobility Agent Solution • FA MAY unicast becon with sequence number 0 to MN indicating registration is gone (mipv4). • Need to add a deRegistration message that can be sent between HA and CoA (MIPv4/v6). • MUST be authenticated, and "unreplayable" • Authentication/replay failure means silently ignore. • Would be nice to specify either "unconditionally revoke" or "allow reregistration" (renegotiate).

  6. Details... • New Registration type - Revocation "Request". • Not really a "request", more like a "notification". • MUST be sent only HA to CoA, or FA to HA. • MN's "revocation request" is the deregistration (lifetime = 0, etc)! • If Revocation Request has been accepted, Revocation Reply MAY be sent, but if not, clearly registration has still been revoked.

  7. Network View – Foreign Domain Foreign Domain Triggered Revocation: (MIPv4-centric) MN FA HA |<--Becon(0)---| |-RevReq(FA-HA)->| |<-RevRep(HA-FA)-| Revoke = e.g. AAA to FA (not shown) Becon(0) = Agent Adv w/seq#=0 RevReq = "Request" with auth, etc. RevRep = optional, wit auth, etc.

  8. Network View – Home Domain Home Domain Triggered Revocation MN FA/CoA HA |<---RevReq----| |<--Becon(0)---| |----RevRep--->| revoke = e.g.AAA to HA (not shown) RevReq = "Request" with auth, etc. Becon(0) = Agent Advert w/seq#=0 RevRep = optional, with auth, etc.

  9. Revocation Message Format 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Agent Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |... (other extensions, e.g. HA-FA authenticator) ... Type: (TBD) Code: Indicates "unconditionally revoke" or "allow rereg". Lifetime: The lifetime of this deRegistration. Home Address: registered address of the MN. Agent Address: address of the agent sending the revocation. * Identifier: used for replay protection (same in req and rep).

  10. Observations • MN will almost certainly attempt to reregister: • FA MUST NOT silently ignore! => MNconfusion! • FA MAY reply with "administratively prohibited", or FA MAY forward to HA to respond. • Different reasons for revocation lead to different reregistration actions. "unconditional" vs. "renegotiate" • MN may then attempt to reregister with different FA, but HA will handle this. • Changes to FA, and HA (obviously), but also to MNs that will colocate to understand HA revoke!

  11. Pitfalls? • Comments from the audience???

  12. Final Thoughts • Multiple Bindings: • HA may revoke any of multiple bindings. • If one of multiple-binding FAs revokes a registration, HA may revoke other of multiple-bindings. • The "R" bit (another use?): • An FA may set the R-bit to be able to inform MNs of other service revocations resulting in MIP revocation.

More Related