[Mip6] comments on draft-le-aaa-mipv6-requirements-03.txt

[Jari Arkko <[e-mail]>]

Hi Franck and others, and thanks for submitting this document.
I think we do need a discussion and requirements for AAA and
MIPv6.

Here are some comments based on reading your document:

>    Mobile IP defines a method that allows a Mobile Node to change its
>    point of attachment to the Internet with minimal service disruption.
>    But Mobile IP in itself does not provide any specific support for
>    mobility across different administrative domains, which limits the
>    applicability of Mobile IP in a large-scale commercial deployment.

I think we need some new or different terms here. I'm not sure "mobility"
is the right term above. Roaming or network access instead? You seem
to use "roam" yourself further in the text.

>    AAA protocols such as Diameter precisely enable mobile users to roam
>    and obtain service in networks that may not necessarily be owned by
>    their home service provider. For Mobile IP to be deployed in
>    commercial networks, there therefore has to be AAA support for the
>    protocol.

Technically, this is not exactly the case. There is no reason why you'd
have to bind network access and mobility service together. In fact,
doing so may limit the deployment of mobility to only those locations
which offer a sufficiently updated network service, AAA infrastructure,
and are willing to provide this service.

Don't get me wrong -- I think AAA support for MIPv6 would be a good
thing. Just that I think the stated reason is not as you write above.
I believe the reason has more to do with the ease at which you can
enroll yourself to a "Mobile IPv6" service. Here AAA can help, in
different ways, not all necessarily binding access and mobility to
each other.

To give you a practical example, the use of EAP authentication is
currently popular in many planned networks and protocols, such as
802.11 or PANA. Now, if you mobile node is doing EAP FOO authentication
to get access, would we really need anything else than a way to
do EAP FOO with your home agent as well? Both the access network
and the home agent could then, independently, contact the user's
authentication server using AAA protocols such as RADIUS or Diameter.

[I'm not necessarily proposing this as the solution, but just
trying to give you an example. It may not be such a great idea
to put EAP into all sorts of protocols beyond network access.
See draft-ietf-eap-rfc2284bis-09.txt for an applicability
statement.]

>   When a client belonging to one administrative domain (called the
>   home domain) roams to another administrative domain (called the
>   foreign domain) and needs to use the local network resources, an
>   attendant in the foreign domain is likely to require that the
>   client provides some credentials that can be authenticated before
>   access to the resources is permitted.  These credentials may be
>   something the foreign domain understands, but in most cases they
>   are assigned by, and understood only by the home domain, and may
>   be used for setting up secure channels with the mobile node.

I agree that this is needed. But I'm not sure we need to set a
requirement for this, as it is a feature which seems to be exhibited
by most current or planned access networks. For instance, systems
that employ 802.1X can do this. UMTS can do this. PANA can do this.
Are you suggesting that where MIPv6 is used, these existing schemes
have to be abandoned and replaced by something new? Or that a second
local authentication needs to take place? Or maybe I'm missing
something obvious...

>    A modification to the basic model that is required is the need to
>    support and utilize Local Security Associations. LSAs have been
>    recently introduced in IETF ([3], [5]). After an initial successful

Some variants of this approach already exist in EAP methods that can
do fast reauthentication or re-attachment.

>    The Diameter Mobile IPv6 Application is a new application extension

Does this mean that a network which currently offers e.g. 802.11i +
RADIUS + IPv6 would be unable to support Mobile IPv6 until the network
has been upgraded to use Diameter? I would really like to promote
Diameter usage, but realistically, I think we need assume that existing
AAA networks are used too, and we should try to place as little new
requirements on them as possible.

For instance, is there a way where we could accommodate MIPv6 AAA
requirements without requiring more than RADIUS EAP or Diameter EAP
support at the AAA infrastructure? Or can we make some parts of the
AAA exchange optional, so that you get *some* functionality even
if you just do basic 802.1X + RADIUS.

>    -  Either AAA server MUST be able to obtain, or to coordinate the
>       allocation of, a suitable IP address for the customer, upon
>       request by the customer
> 
>    -  AAA servers MUST be able to identify the client by some means
>       other than its IP address
> 
>    And so are the derived ones such as:
> 
>    -  Policy in the home domain may dictate that the home agent instead
>       of the AAAH manages the allocation of the home IP address for the
>       mobile node. AAA servers MUST be able to coordinate the allocation
>       of an IP address for the mobile node at least in this way.

All of these requirements appear to be supported by Diameter NASREQ
(for instance).

>    -  In the Diameter support for MIPv6, mobiles nodes SHOULD use the
>       NAI

Hmm... the NAI is more or less built-in to AAA protocols. But I think
you mean that the mobile node - home agent communication SHOULD use
the NAI?

>    This implies that at the initial registration the mobile node needs
>    to be authenticated and authorized, and mobility procedures need to
>    be performed (e.g. between the foreign agent and the home agent) to
>    guarantee the mobile node can use Mobile IP.

Foreign agent?

>    As a result, latency is reduced
>    by handling the initial registration in conjunction with AAA and the
>    mobile IP mobility agents.

I'm not sure I understood the procedure from this. So the initial exchange
is between mobile node - foreign agent - home agent, and the subsequent
exchanges use a reduced scheme?

>    Moreover, subsequent registrations, and authentication could be
>    optimized thanks to LSA.

Re-use of an existing (local) SA across movements is possible, but
there are a couple of interesting issues that you need to consider.
For instance, some fast re-auth schemes in wireless LAN environments
have suffered from issues discussed in Sections 1.4 and 1.4.1 of
draft-ietf-eap-keying-01.txt. I'm not 100% convinced that we can
optimize without losing some of the typical AAA authorization checks.
It may be possible to do optimization for those cases where the home
AAA explicitly informs the local AAA that e.g. no dynamic checks are
being made.

In conclusion, I think your document makes a good job at listing
the requirements, but I see the following issues in front of
us that we should discuss:

1) Is the "MIPv6 AAA" a replacement for existing AAA mechanisms
    designed for purely roaming (non-MIP) nodes? If not, we should
    concentrate only on the additional MIPv6-related requirements
    here and not on the basic access related requirements which form
    the majority of what you listed above.

    If yes, I see a big deployment problem. It would be better for
    mobile IPv6 to adapt to existing access networks than to try
    change them.

2) Can we live with RADIUS EAP and Diameter EAP for the network
    access part even for MIPv6 nodes?

3) What exactly are the MIPv6-specific features that we need
    from AAA? LSA? Maybe. The care-of address verification that
    Francis mentioned? Maybe. Piggybacking both BUs and access
    auth in the same messages, as suggested e.g. in draft-josefsson?
    (Not sure how that would work; IP is not up at the time you
    are doing EAP.) What else?

--Jari



_______________________________________________
Mip6 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mip6