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 you mean a preshared secret? A security association comprises far more than just a key. There is new nomenclature I have not evaluated the security of the scheme in this section, since it depends on another draft, and possibly on the security of MobileIP itself. 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 local firewalls to open up some holes? The administrator needs to open up such holes 5.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 foreign agents know authoritatively who each other are. Then again, that's always been my main complaint about AAA. But here they're handing out keys. The draft uses TLS or IPSec to authenticate the mobility agents 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 ::= { 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