1 / 7

AAA-HA Interface Goals for MIP6 WG

This draft outlines the goals for the AAA-HA interface in the MIP6 working group, including support for inactive peer detection and mobile service authorization verification. It also discusses the need for the HA to act as a pass-through EAP authenticator and communicate the HoA and FQDN of the MN to the AAAH server. Additionally, it introduces a new goal for supporting different AAA servers for network access and mobility service authentication.

jdegroot
Download Presentation

AAA-HA Interface Goals for MIP6 WG

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. San Diego, November 2006 IETF 67th – mip6 WG Goals for AAA-HA interface (draft-ietf-mip6-aaa-ha-goals-03) Gerardo Giaretta Ivano Guardini Elena Demaria Julien Bournelle Rafa Lopez

  2. I-D status • WGLC from Oct 3rd to Oct 18th • detailed reviews from Yoshi, Madjid, Vidya and Hannes • Most comments are editorial • Some discussions/comments about rfc4285 support • Next Step: new version after this meeting to be sent to IESG review

  3. Goals review • G1.5 removed • The AAA-HA interface SHOULD support inactive peer detection. This functionality can be used by the AAAH server to maintain a list of active Has • Motivation: this can be done outside the AAA protocol • G2.2 text changed • Old Text: The HA SHOULD be able to query the AAAH server to verify Mobile IPv6 service authorization for the mobile node • New Text: The HA MUST be able to query the AAAH server to verify Mobile IPv6 service authorization for the mobile node

  4. Goals review (cont’d) • G4.1 text changed • Old text: The AAA-HA interface MUST support pass-through EAP authentication with the HA working as EAP authenticator operating in pass-through mode and the AAAH server working as back-end authentication server • New Text: The AAA-HA interface MUST allow the HA to act as a pass-through EAP authenticator • G5.1 text changed • Old text: The HA SHOULD be able to communicate to the AAAH server the HoA allocated to the MN (e.g., for allowing the AAAH server to perform a DNS update on behalf of the MN) • New Text: The HA SHOULD be able to communicate to the AAAH server the HoA allocated to the MN and the FQDN of the MN (e.g., for allowing the AAAH server to perform a DNS update on behalf of the MN)

  5. Goals review (cont’d) • One new Goal added • The overall AAA solution for integrated scenario MUST support the scenario where the AAA server of the ASA/MSA used for network access authentication is different from the AAA server used for mobility service authentication and authorization

  6. Open issues • Proposal by Hannes to rephrase all goals in terms of “AAA protocol MUST/SHOULD/MAY…” • in order to refer to the design of the protocol rather its usage • Example: • G5.1  The HA SHOULD be able to communicate to the AAAH server the Home Address allocated to the MN (e.g., for allowing the AAAHserver to perform a DNS update on behalf of the MN) • G5.1  The AAA protocol extension MUST allow Home Address to becommunicated from the HA to the MN. It is, however, not necessary to use it

  7. RFC 4285 support • Some comments about rfc4285 requirements • Not enough interest so far in order to include rfc4285 support • we do not have any official bootstrapping document in MIP6 WG for rfc4285 SA • The ongoing design of the AAA-HA Diameter application in DIME WG is based on the split of authentication and authorization steps • rfc 4285 support will only require modifications to the authentication application • the authorization application can be designed in a generic way (both for IPsec and rfc4285 SAs)

More Related