Subject: [Mip6] comments on draft-ohnishi-mip6-aaa-problem-statement-00.txt

From: Jari Arkko <[email-masked]>
Date: Sat, 28 Feb 2004 16:16:39 +0200

Hi Ohnish and others, and thank you as well for submitting this
requirements document. Like I said before, we need a discussion
in this space.

I generally agree with your requirements. Some comments below:

>    If MN moves across different administrative domains in a 
>    commercial network, Mobile IPv6 requires AAA's support.

As I stated before, strictly speaking, its network access that
requires clients to have credentials and access networks to employ
AAA.

But as defined today at least, Mobile IPv6 does not require it.
It maybe beneficial to have AAA support in MIPv6, though.

And then we have another issue having the right type of credentials
(e.g. passwords vs. IPsec SAs) for large-scale deployment. In fact,
I sense that this is probably the crucial issue.

Unless... access network providers want a piece of the "mobility
business", i.e., want to be involved in the transactions for
non-technical reasons.

>    it should be 
>    noted that the informative description is not advocating or 
>    recommending the same approach adopted to Mobile IPv4 to be used for 
>    Mobile IPv6. 

This is wise.

> 2.1 Roaming to foreign domain 
>     
>    Mobile IPv6 supports MN's mobility. But if MN moves to a foreign 
>    domain, the foreign domain requires the way of Authentication, 
>    Authorization and Accounting. RFC2977 shows requirements for this 
>    scheme.  RFC2977 shows  the applications of AAA to the Mobile IP, e.g. 
>    the basic model, the local payment model, the local home agent model 
>    and so on. 

When a node with HTTP support roams to a different domain, its going
to need AAA or it won't get access. This does not necessarily mean
that we have to add AAA support HTTP. So, I think it would be valuable
to break down the above requirement in smaller pieces that talk about
MIPv6 specific requirements. For instance, it may be that local home
agent assignment is such a requirement.

>    A solution for dynamically and securely assigning 
>    home address prefix to mobile node with involving an appropriate 
>    authentication and authorization protocol is demanded. 

I agree, though I worry what this means protocol-wise. Right now,
we would not like to add a new AAA feature to basic IPv6 discovery
functions. Existing link layers aren't easily modified, and EAP may
not be the appropriate vehicle to download a lot of material and
parameters for IP layer functions. So how can we realize this
function?

>    In Mobile IPv6 architecture, there is no FA unlike Mobile IPv4. The 
>    fundamental problem that needs to be solved is to support the usage   
>    cases described in Section 2 without introducing FA in Mobile IPv6. 
>    This would lead to a need to define a MIPv6 Service Aware AAA 
>    Attendant (MSAAA), which is an AAA attendant to provide AAA for 
>    Mobile IPv6 service for MN.  The MSAAA may be integrated with an AAA 
>    attendant of other protocol or service, or may be integrated with 
>    MIPv6 home agent, depending on Mobile IPv6 service models.  The 
>    protocol to transfer information between HA and AAA server is needed 
>    in every above MSAAA deployment scenarios. 

I like the possibility of placing the MSAAA in the home agent.
Placing them in the access network may limit deployment to
just some specific network type that can be designed with this in
mind.

--Jari

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

---

From: Hiroyuki OHNISHI <[email-masked]>
Date: Sun, 29 Feb 2004 20:49:04 +0900

Hi Jari,

Thank you for your comments.

On Sat, 28 Feb 2004 16:16:39 +0200

> It maybe beneficial to have AAA support in MIPv6, though.

As you mentioned, "roaming" is related to network access control.
I think AAA for network access and AAA for Mobile IPv6 are different.
Since this sentense seems to imply AAA for network access, I think it is
better to delete this sentense.

> agent assignment is such a requirement.

As you mentioned, local home agent assignment is one requirement.
And local home assignment and bootstrapping betwenn local HA and MN are
also requirements.
These requirements can be stated in 2.3-2.4. So I can delete this
section 2.1.  But I am not sure how AAA for Mobile IPv6 should be
related to AAA for network access now. 

> parameters for IP layer functions. So how can we realize this

I assume using some host configuration protocols to assign such kind of
Mobile IPv6 specific information.

> just some specific network type that can be designed with this in

If MN knows HA's address, you can deploy MSAAA into HA.  But I want to
handle dynamic HA address assignment scenario. In that case, I think deployment
of MSAAA to HA does not work well.

1--
Hiroyuki

-- 
Hiroyuki OHNISHI <[email-masked]>

---

From: Jari Arkko <[email-masked]>
Date: Sun, 29 Feb 2004 14:15:25 +0200

Hi Hiroyuki and thanks for your quick response! What you

> Mobile IPv6 specific information.

Can you name some specific example as to what protocol you are thinking?
Presumably, the information would have to be secured somehow, at least
if you are handing out keys to access the home agent. DHCP? ND, but
that would presumably not be secure? SEND? EAP TLVs? 802.11 IEs?

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 26 Feb 2004 23:30:35 -0800

Hi Jari,

> that would presumably not be secure? SEND? EAP TLVs? 802.11 IEs?

In my personal opinion, DHCP is the most appropriate protocol.  I am
not viewing ND as a general-purpose host configuration protocol that
is appropriate to carry Mobile IPv6 parameters in visiting networks.
As you mentioned, the information needs to be secured.  More
specifically the information needs to be at least integrity protected
and replay protected.  RFC3118 (DHCP authentication) satisfies such a
requirement.  Also, this kind of model would require the cryptographic
key used for DHCP authentication to be bootstrapped from a AAA-Key
derived from *any* EAP method that can generate keys.
draft-yegin-eap-boot-rfc3118-00.txt describes such a method and I
think that the draft is important.

Anyway, this is more than problem statement and I would like to focus
on problem statement at this moment...

Best regards,

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 26 Feb 2004 23:42:13 -0800

Correction: "RFC3118 (DHCP authentication)" -> "RFC3315".

Yoshihiro Ohba

---

From: "James Kempf" <[email-masked]>
Date: Sun, 29 Feb 2004 15:58:09 -0800

> better to delete this sentense.

It is also related to charging for mobility service. The access network
provider might want to charge differentially for users that move and those
that want to stay at a fixed location.

> > business", i.e., want to be involved in the transactions for

They might. Some ISPs today charge different rates for fixed IP addresses as
opposed to DHCP allocated addresses. There's no technical reason for this
(and opinions vary about its desirability).

            jak

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 29 Feb 2004 17:45:33 -0800 (PST)

> that want to stay at a fixed location.

The distinction between "mobilty" and "mobile IP" is critical here.

I don't think the access network can charge differently for
mobility without help from the home AAA support. For instance,
the access network here in the Lotte hotel can't know that
a day ago I was in California.

You can try to charge extra for mobile IP, but wouldn't that mean that
folks would use mobility at other layers e.g. client-only protocols
that don't need reachability at a fixed IP address?

Given that we want to increase deployment of mobile IP,
since it is a platform for interesting upper layer services, having
the access provider charge more for mobile IP seems counterproductive.

That doesn't prevent the home provider to charge for maintaining the fixed
IP address precence and tunneling, but you actually want those charges to
be small to drive deployment.

   Erik

---

From: "James Kempf" <[email-masked]>
Date: Sun, 29 Feb 2004 20:04:38 -0800

> that don't need reachability at a fixed IP address?

I was thinking of an access network provider that wanted to charge more for
a client that changed its address "frequently" (where frequently is somewhat
ill defined) as opposed to one that kept the same address for a long
session.

Mobile IP has certain fixed per node costs in terms of signaling that are
definitely not there for a node that gets a lease on its DHCP address and
hangs on to it until the lease expires. That would be the justification for
charging more.

> the access provider charge more for mobile IP seems counterproductive.

Like I said, people's opinions about whether or not this is desirable can
vary. :-) But I don't think the IETF should be engineering the protocol to
favor one business model over another (see draft-iab-e2e-futures-txt for a
discussion of tussles and how standards should work in the face of them). So
far, I don't see anything in the protocol that does.

> be small to drive deployment.

Sure. But XYZ network provider might view the extra capacity they need to
install in their access network for Mobile IP signaling as a reason for
charging. Though, in the end, it is probably far less than than what they
need to accommodate spam.

            jak