Subject: [Mip6] Comments on draft-zhang-mip6-find-reg-ha-00.txt

From: Jari Arkko <[email-masked]>
Date: Tue, 07 Mar 2006 13:02:27 +0200

I read the draft. Its was easy to read and discussed a function
that it is potentially useful. However, I do have a number
of comments. Lets start with some details first:

>1.1. Retrieve Mobile IPv6 state for AAA service 
>
>   In order to use mobile IPv6 service, a mobile node SHOULD be 
>   authenticated and authorized by AAA server which is located in the 
>   home network of mobile node. As stated in [GOALS], the AAAH server 
>   SHOULD be able to retrieve the Mobile IPv6 state associated with a 
>   specific MN from the correspondent HA. This MAY be useful to 
>   periodically verify the Mobile IPv6 service status. 
>
Wouldn't this be a part of the usual (already existing) AAA
transactions? That is, you can make the AAA system stateful
in the sense that you track what sessions are still in progress.
You can even send a disconnect from the AAA server to the
entity that has the session. Or ask to get frequent updates
when something changes.

>1.2. Retrieve Location information for Location service 
>  
>
>   When mobile node is roaming on foreign networks, there maybe some 
>   requirements to locate the position of mobile node, such as whether 
>   the mobile node is in home network. To implement this function, the 
>   location server needs to query the status of the mobile node.  
>  
>
Would draft-ietf-geopriv-radius-05.txt be a part of the answer here?
Or is there a need to deliver care-of address information instead
of real location information? In any case, presumably additional
attributes could be used to provide address-based information
if that was really needed.

What about privacy issues... they are not treated in the draft
at all. I do not wish my location information to be revealed
without checks, even if its just a question of home/away
indication.

>5. Message types and Modifications 
>
>   There are four messages in this protocol, such as HALocReq, HALocRes, 
>   HASol, and HAAdv. All of these messages are ICMPv6 message extended 
>   for the protocol. 
>
This choice of protocol has some practical implications. For instance,
in order to handle privacy, you would propably need to employ IPsec
and set the selectors to these new ICMP message types. In practice
this means that there'd be some sort of security associations or
IKE credentials set up between the home agents and the potential
application servers that need this information. But IPsec and anycast
may not be a protocol combination that works well. And in any case,
setting up these associations would be quite a burden. And with
IPsec it would be impossible, I think, to make application-level
decisions about authorization. For instance, lets assume that both
you and me are served by the same set of HAs. If I want to give
my friend access to my home/away information (and possibly more
detailed status data via the used HA), how do I do that? If the friend
uses an application server X and we set up a security association
between X and the home agent set, does that mean that my friend
can also get your information, not just mine? What about everyone
else who uses X?

A couple of other protocol choices come to mind:

- Just observe the ND level exchanges -- this would be possible
  within application servers on the home link.

- Use AAA. Perhaps even the existing mechanisms.

- Something at application layer.

- Talking to the mobile node in question, directly.

There's probably even other choices.

As an overall comment, I would first suggest that more effort
would be spent on thinking where this function would be
useful and what specific scenarios need to be supported.
The motivation part lacked detail and justification
for not being able to use existing protocols. Secondly, I would
also start thinking on what the right architecture for the solution
would be. I am not convinced that ICMP is the way to go here.

--Jari

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

---

From: Zhang Jian <[email-masked]>
Date: Wed, 08 Mar 2006 18:55:53 +0800

Thanks for your comments, Please see inline my answers.
We can solve this problem together.

Jian

----- Original Message ----- 
From: "Jari Arkko" <[email-masked]>
To: "Mobile IPv6 Mailing List" <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 07, 2006 7:02 PM
Subject: [Mip6] Comments on draft-zhang-mip6-find-reg-ha-00.txt

> entity that has the session. Or ask to get frequent updates

=>Yes, this can be a part of the AAA transactions. There is a mechanism in 
draft-giaretta-mip6-authorization-eap-02. But I think it can only used for AAA
service. What about other services? So I submitted this draft which is a general
mechanism.

> if that was really needed.

=>The draft-ietf-geopriv-radius-05.txt does not support mobile IPv6.
Am I right? 
Yes, there are two kinds of information, care-of address information and 
real location information. Based on this draft, application server can know 
the home agent which mobile node was registered to. The application server 
can retrieve the information of mobile, such as care-of address. The application
server can contact with access router of mobile node to retrieve the real 
location information of mobile node, but it is out of scope of this draft.

> without checks, even if its just a question of home/away

=>This operation can only be performed by carriers, not for CN.
So CN cannot know the mobile node's location by this method.

> can also get your information, not just mine? What about everyone

=>The method described in this draft can only be used by carrier, not for 
other end users. Because of this assumption, I think there may be some 
trust relationship between application servers and home agent.
But, the security is really a problem for further discuss.

>  within application servers on the home link.
=>Yes, it can work only the application servers on the home link.
If the application servers do not on home link, it can not work.

> - Use AAA. Perhaps even the existing mechanisms.
=>Yes, it can work for AAA service. What about other services?
If the mobile node is not honest, how to deal with it?
When the mobile is roaming on foreign network, the message may be 
intercepted by someone. It is another problem.
If there are lots of mobile nodes to inquire, it may be a heavy load for 
AAA server and network, espcially in 3GPP network.

> There's probably even other choices.
=> Yes, there may be other solutions. We can discuss the best solution.

> would be. I am not convinced that ICMP is the way to go here.
=>Yes, ICMP may be not the best way. We can find other method.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 08 Mar 2006 19:04:55 +0200

>service. What about other services? So I submitted this draft which is a general
It seems that even basic RFC 3588 could already do a part of this,
too, or at least the AAA server will be aware of what HA is being
used.

It wasn't clear to me if draft-giaraetta allows a random application server
to retrieve node X's current HA via AAA. Does it?

>=>The draft-ietf-geopriv-radius-05.txt does not support mobile IPv6.
Depends. The geopriv draft allows a "service node" (e.g. HA, NAS, AP) to
tell
the AAA network where the client is. It can do this both initially, as well
as update the information during the session. Does this suffice for what
you want to do? Presumably this depends on the requirements...

>So CN cannot know the mobile node's location by this method.
Right. But how do you know who are the carriers... what I was saying
is that the use of ICMP appears to lead to a very low granularity in
making decisions about who gets this information.

>trust relationship between application servers and home agent.
Right. The main issue is that using ICMP and IPsec, its hard to make
this data available in places where it would potentially be useful.

>But, the security is really a problem for further discuss.
Yes.

>If the application servers do not on home link, it can not work.
Right. But the cost of this method in terms of specification effort,
infrastructure, implementation is very low. It may be that there's
a lot of bang for the buck...

>=> Yes, there may be other solutions. We can discuss the best solution.
Yep.

--Jari

---

From: Zhang Jian <[email-masked]>
Date: Thu, 09 Mar 2006 19:56:39 +0800

> to retrieve node X's current HA via AAA. Does it?
I'm not sure whether Diameter can provide this function. Even it can provide
this function, I think it can only support AAA service. At present, AAA server
don't aware of what HA is being used, because no specification describes this
mechanism. 
Draft-giaraetta only support AAA service. It do not allows a random application
server to retrieve nods X's current HA vis AAA.

> you want to do? Presumably this depends on the requirements...
In the basic specification of mobile IPv6, there is not description about wheter
it is needed to do authentication and authorization again while mobile node 
hand over.  If it is needed, it will increase the delay of handover.
The location service in our draft should be call as location management.
There may be some other service that need this mechanism in future.

> making decisions about who gets this information.
Yes, this is a security problem that I didn't consider, it should be further complement.

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 9 Mar 2006 13:36:59 +0100

Hi,

> don't aware of what HA is being used, because no specification describes this

 this is not really true. In the 2 bootstrapping mechanism for mip6
 (split and integrated scenario), the MN uses IKEv2 with the HA. If EAP
 is used by the HA to authenticate the MN, it may rely on the home
 Diameter EAP server of the MN. In this case, the AAA knows the HA used
 by the MN.

> server to retrieve nods X's current HA vis AAA.

 in this draft, the AAA is in charge of allocating the HA for the MN.

 My 2 cents,

 Julien Bournelle

-- 
julien.bournelle at int-evry.fr

---

From: Jari Arkko <[email-masked]>
Date: Thu, 09 Mar 2006 14:45:57 +0200

>don't aware of what HA is being used, because no specification describes this
Diameter servers are capable of sending messages to the entity that
is providing the service (NAS or HA or AP or ...). As a part of this,
they have to be aware where the service is being provided.

>server to retrieve nods X's current HA vis AAA.
I think there are two parts - the infrastructure (= AAA server) finding
out, and the application servering finding out this from the infrastructure.
I do not think the latter has been specified anywhere.

But, as you say, we might not even want to couple this to AAA.

The reason that I brought it up was that there may be a subset
of services where the existing AAA mechanisms are sufficient.
For instance, any location-based logic at the AAA server side
would probably be doable. One of the decisions that we have to
make regarding this work is whether there's sufficient demand
to actually do something in this space, or whether the existing
mechanisms cover the main needs already.

>There may be some other service that need this mechanism in future.
Sure. I agree that you shouldn't need to re-authenticate. But that
doesn't rule out the home agent sending some parallel messages
to some infrastructure component.

--Jari

---

From: Zhang Jian <[email-masked]>
Date: Thu, 09 Mar 2006 21:23:43 +0800

> Diameter EAP server of the MN. In this case, the AAA knows the HA used
The question is whether the AAA server records which HA the mobile node belongs to.
If AAA server does not record this, there should have a mechanism to provide.
If AAA server records this, other services can get the information from AAA server.
But I'm not sure whether it is a good idea to get this information from AAA server.
This may be a burden for AAA server.

> in this draft, the AAA is in charge of allocating the HA for the MN.
Please see the answer upper.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 09 Mar 2006 15:48:37 +0200

>If AAA server does not record this, there should have a mechanism to provide.
It has to, if it intends to support other features such as server
initiated disconnect.

--Jari

---

From: Zhang Jian <[email-masked]>
Date: Thu, 09 Mar 2006 21:52:28 +0800

> mechanisms cover the main needs already.
Yes, you are right. AAA may know the information, but we might not want
to couple this to AAA. The reason I submitted this draft is that we can provide
the function by basic specification, and do not depend on other service, such as
AAA service. In future deployment of mobile IPv6, there might be some other
services that need this function. If every service get this information from AAA 
server, it might be a heavy burden for AAA server. We could get this information
directly from home agent.

> to some infrastructure component.
Yes, home agent can send some parallel messages to some infrastructure 
component. In this case, some application server should record this information.
If there are lots of mobile node, application server must have a large database to 
save the information. And there might be lots of messages in network.
So, we think it might be better to retrieve the information when needed.

  Jian