1 / 11

Mobile IPv4 – Diameter Draft Status

Mobile IPv4 – Diameter Draft Status. Tom Hiller Lucent Technologies. AAA-Keys and MIP-Diameter Status. Thomas Narten performed in-depth review Thomas made suggestions for terminology improvement in MIP-Diameter, which have been acted upon. Draft will be resubmitted. In IESG review.

kathrynf
Download Presentation

Mobile IPv4 – Diameter Draft Status

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. Mobile IPv4 – Diameter Draft Status Tom Hiller Lucent Technologies

  2. AAA-Keys and MIP-Diameter Status • Thomas Narten performed in-depth review • Thomas made suggestions for terminology improvement in MIP-Diameter, which have been acted upon. Draft will be resubmitted. • In IESG review. • Thomas currently reviewing AAA-Keys MIP extension names. • Next step is to start an IETF last call. • Remaining slides address issues and highlight changes from the last IETF meeting

  3. Issue 386 • Rationale/Explanation of issue: • 1.6: What is a "preconfigured shared security association"? Do youmean a preshared secret? A security association comprises far morethan just a key.There is new nomenclature • I have not evaluated the security of the scheme in this section, sinceit depends on another draft, and possibly on the security of MobileIPitself. Can we really even consider this draft until those are done?The AAA-Keys draft is in Publication Requested • 1.10: What firewall rules? Are the agents supposed to tell their localfirewalls to open up some holes?The administrator needs to open up such holes5.2: 64 bits is not sufficient for a key. Why not just mandate 128,instead of strongly recommending it?Done. • 5: I confess that it still isn't clear to me how the home and foreignagents know authoritatively who each other are. Then again, that'salways been my main complaint about AAA. But here they're handing outkeys.The draft uses TLS or IPSec to authenticate the mobilityagents and protect the keys from being seen by agents without a need to know • (The above comment is from two years ago and the draft considerably changed)

  4. Issue 432 • Rationale/Explanation of issue: • Section 4.0 of draft-ietf-aaa-diameter-mobileip-14.txt says that MIP-Host-Agent-Host AVP is of type DiameterIdentity:MIP-Home-Agent-  348  4.11    DiamIdent  | M  |  P  |    |  V  | N  |Host                                  |    |     |    |     |    |On the other hand, in Section 4.11 the same AVP is defined as type Grouped:      MIP-Home-Agent-Host ::= < AVP Header: 348 >                               { Destination-Realm }                               { Destination-Host }                             * [ AVP ]                          • Which is correct?The second case is correct; will fix the first case

  5. Issue 445 • The document is incomprehensible. … • Introduction rewritten

  6. IESG Review • Steve Bellovin: 2.2 writes “Security considerations may require that the HAR be sent directly from the AAAH to the HA without the use of intermediary Diameter agents. This requires that a security association between the AAAH and HA be established, as in Figure 4” • If the HA is in the foreign network, how does AAAH get suitable information to set up a secure session? • The AAAH gets the HA identity in the candidate HA AVP from the visited network. The HA accepts the IPSec/TLS connection from the AAAH if the AAAH is a roaming buddy or if the HA previously redirected a proxied HAR from the AAAH.

  7. IESG Review: Symmetric Key • Historically, Mobile IP uses the same key for both directions, e.g., MN-HA and HA-MN • This draft follows that convention • Question for Steve Bellovin: What is the security vulnerability of using the same key in both directions?

  8. HA-FA Mobility Security Associations • HA-FA key scaling • Previous draft had one HA-FA mobility security association per mobile • This would be a major burden on Mobile IP entities, many of which are built from routers and therefore light on memory • The draft outlines a discard policy to discard previous HA-FA keys and SPIs between an FA and HA pair, so that there is only one such key most of the time.

  9. When to Accept an IPSec/TLS Connection • Assuming a valid certificate, when should the AAAH or HA accept an IPSec or TLS request from the FA (AAAH)? • The AAAH accepts IPSec/TLS requests from FAs owned by roaming buddies; the HA accepts IPSec/TLS connections from AAAHs owned by roaming buddies • The AAAH or (HA) first receives an AMR (HAR) from the FA (AAAH), and responds with redirection to itself. Subsequently the AAAH (HA) receives an IPSec/TLS connection request from the FA (AAAH) and accepts the connection. This permits transitive roaming agreements that are not reflected locally on a roaming list in the AAAH or HA

  10. FA Tunnel Address • The FA Tunnel address is not authenticated in “Mobile IP Diameter”, i.e., there is no way to prove it belongs to the actual “FA entity” that makes AAA requests • Now, the draft points out that if the FA COA address equals the AAA FA address of IPSec and TLS connections, then the FA tunnel address may be presumed to truly belong to the FA • However in practice the FA AAA address is different than the FA CoA (tunnel) address. Such systems are already deployed

  11. New Revision • Adopts through out terms like “MN-HA” instead of “mobile home”; this improves readability

More Related