DIME WG IETF71

1
DIME WGIETF-71

• Diameter MIPv6 HA - HAAA Support
• draft-ietf-dime-mip6-split-07
• March, 2008
• Jouni Korhonen

2
MIP6 Split Scenario

• Defines the HA to AAA interface
• Bootstrapping of MN to HA security association
• Bootstrapping of HoA HNP
• Support for both RFC4877 and RFC4825bis
• Defines a new application
• Reuses existing application commands for RFC4877
  bootstrapping
• New commands for RFC4285bis
• MRM MAM
• HA does replay protection

--------
Diameter
Server
--------

Back-End Diameter MIPv6
Protocol
HAlt-gtAAA Server
Support Interaction
(this document)
v
---------
--------------- Mobile Front-End
Protocol Home Agent / Node
lt--------------------------Diameter Client
--------- IKEv2 or RFC 4285
---------------
3
Changes since IETF70

• Version -06 -gt -07
• Replay protection -gt clarified that it is only
  done in the HA
• CoA handling -gt removed from most commands as it
  is not known during the bootstrap
• Guidance -gt include the IKE IDr payload into the
  Called-Session-Id
• Guidance -gt when to send accounting
• Auth/Authz handling -gt AAA interactions only
  during the bootstrap or the initial attach
• AVP corrections -gt new MIP-MN-HA-MSA AVP instead
  of RFC4004 MIP-MN-to-HA-MSA AVP
• ABNF corrections -gt removed duplicates, minimum
  number of mandatory AVPs etc
• Thanks to Ahmad Gerardo for thorough reviews

4
Supported MN auth authz scenarios

• The HA-AAA auth/authz (IKEv2 or BU) is used for
  the initial attachment.. subsequent BUs are
  processed in the HA only
• Using IKEv2 to auth/authz the MN
• EAP-based, reuses DER/DEA
• Certificate based, reuses AAR/AAA
• PSK-based, reuses AAR/AAA
• Using Authentication Option to auth/authz the MN
• 3GPP2 model, the AAA calculates session keys
  based on the MN-AAA Mobility Option, uses new
  MRM/MAM
• A pull model is also possible, where the AAA
  calculates session keys e.g. based on access
  authentication and the HA just retrieves the key
• Allowed by the MRM/MAM command ABNFs

5
How to use MIP6-Feature-Vector

• MIP6-Feature-Vector allows end-to-end capability
  negotiation between the HA and the AAA server
• The HA includes supported/desired capabilities in
  the request message
• The AAA includes those capabilities that are
  supported and authorized by the policy in the
  reply message
• The AAA may also include capabilities that the HA
  did not ask for, but usually that does not make
  sense (i.e. the HA may ignore them)
• Capabilities defined in this specification
• RO_SUPPORTED route optimization per
  subscription basis
• USER_TRAFFIC_ENCRYPTION (dis)allow MN-HA user
  traffic encryption per subscription basis

6
Open issues next steps

• Clarify the authorization text
• IKEv2 -gt DER/DEA or AAR/AAA used only during the
  bootstrap
• Auth Option -gt MRM/MAM used only during the
  initial registration
• Define a new application for RFC4285 handling?
• Now we have one application for both IKEv2 and
  Auth Option messages, which does not make sense
  if the HA and the AAA is going to support only
  one type of MIP6 bootstrapping etc
• The I-D is now in WGLC.. after that to IESG ASAP

7
Questions comments?