Subject: [AAA-WG]: [issue] MN starting at Home

From: Sivasundar Ramamurthy <[email-masked]>
Date: Wed, 13 Mar 2002 15:07:49 -0800 (PST)

Hello,

I am not sure if this scenario has been considered by the Mobile IP
application draft.

Some MN might employ the policy to turn off security in data
communication when at home. But the HA advertisement alone may not
enough for the MN to "decide" it is at home, since it could be
spoofed. So when the MN is starting at home, it would still rely on a
de-registration request and a successful reply in order to verify that
it IS at home.

Assuming that this approach is reasonable, an MN starting at home
would recieve HA advertisments and would still send a de-registration
request to the HA. But since it does not have any keys to the HA, the
MN will make a AAA request, which can be processed by the HA only via
AAA (just like a request from a co-located MN).

Does the draft implicity says that the HA cannot send AMR if the
request is not for a co-located MN (and not for de-registration)? If
yes, can we change it?

If no, can we define some protocol by which the AAAH can respond to
such AMRs with an AMA, just like when the co-located flag was turned
on in the MIP-Feature-Vector?

thanks!

Siva

---

From: "Fredrik Johansson" <[email-masked]>
Date: Thu, 14 Mar 2002 20:27:01 +0100

Hi,

I guess there are a couple ways of doing this.

alt 1.
the HA sends the AMR and receives the AMA and then issues a disconnect  at
the same time as it replies to the MN.

alt2.
the AAAH will notice that the lifetime of the session is set to 0, thus we
interpret this as a deregistration (correct me if I'm wrong but 0 isn't used
for something else, is it?)

alt3.
define a new flag in the mip-feature-vector that tells the AAAH that it is a
deregistration but you still would like the mn to be authenticated.

Any preferences?

/fredrik

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>Sivasundar Ramamurthy
>Sent: den 14 mars 2002 00:08
>To: AAA Working Group
>Subject: [AAA-WG]: [issue] MN starting at Home
>
>
>
>Hello,
>

---

From: Sivasundar Ramamurthy <[email-masked]>
Date: Thu, 14 Mar 2002 12:08:27 -0800 (PST)

Hi,

There are two issues/problems to solve here.

1. Letting the AAAH know that the purpose of the AMR is only to
authenticate the MN and to get a key, and _not_ to provide any service
to the MN.
 
2. Making the AAAH process the AMR just like when the co-located
flag was set in the Feature-Vector. That is, the AAAH can directly
return an AMA to the HA instead of the normal AMR-HAR-HAA-AMA
message cycle (which will all be exchanged between the HA and the
AAAH!).

Alt 2 or 3 can be used to acheive this. Alt 3 might be the cleaner way
since this _seems_ to be a Mobile IP specific issue :-)

thanks,

Siva

> >on in the MIP-Feature-Vector?

Thanks,

Siva

====================================
Sivasundar Ramamurthy		
(She-va-su-ndar Ra-ma-moor-thee)

Engineer, Mobile IP Project
Hewlett Packard
(408) 447 7255
====================================

---

From: Tony Johansson <[email-masked]>
Date: Thu, 14 Mar 2002 17:54:53 -0800

Hi Siva,

please find comments embedded...

/Tony

> AAA (just like a request from a co-located MN).

Well, you can not have a HA without a valid SA (i.e. MN-HA session keys).
Thus, if your SA has expired you must re-register in order to keep the HA.

So, your assumption above is not really possible within the scope of this
draft.

---

From: Sivasundar Ramamurthy <[email-masked]>
Date: Thu, 14 Mar 2002 18:36:22 -0800 (PST)

Hi Tony,

> Thus, if your SA has expired you must re-register in order to keep the HA.

But a MN can be configured with a static HA and to use AAA to get
a MN-HA SA, right? 

If so, the scenario I am referring to is for such an MN that starts
(boots up) at home and hears its HA adverts. It will rely on a de-reg
request to confirm that it IS at home. But since it just booted up, it
has no keys to the HA and will thus make the request a AAA request.

Am I missing something that makes this scenario not possible?

thanks,

Siva

---

From: Tony Johansson <[email-masked]>
Date: Thu, 14 Mar 2002 19:45:36 -0800

> But a MN can be configured with a static HA and to use AAA to get

No, if you have a static HA configured you would also have a static MN-HA SA.
Thus, Mobile IPv4.

In the Diameter and Mobile IPv4 case, the MN may request to get a specific HA,
but the AAAH may overrun that request and assign another HA. So, the MN does not
really know its assigned HA until the AAAH has approved it and distributed
session keys (SAs).

IMHO, it would be wrong to say that the MN can really know its HA without a
valid MN-HA SA in the case of Diameter and Mobile IPv4.

/Tony

> request to confirm that it IS at home.

> But since it just booted up, it

---

From: "Fredrik Johansson" <[email-masked]>
Date: Fri, 15 Mar 2002 13:25:19 +0100

Tony,

see comments inline.

/fredrik

>Tony Johansson
>Sent: den 15 mars 2002 04:46
>To: Sivasundar Ramamurthy
>Cc: AAA Working Group
>Subject: Re: [AAA-WG]: [issue] MN starting at Home
>
>
>
>

Why, it must be possible to have a "fallback HA" configured. Just consider
the co-located case, how would the MN register if it doesn't have a
"default" HA? It doesn't speak Diameter and it has no FA to send the request
to. i.e. it has to send the request directly to a HA.

>valid MN-HA SA in the case of Diameter and Mobile IPv4.

No, why shouldn't it get session keys for the session with the use of
diameter as in a FA registered MN?

---

From: Tony Johansson <[email-masked]>
Date: Fri, 15 Mar 2002 12:09:31 -0800

Comments inline......

> to. i.e. it has to send the request directly to a HA.

I'm sorry for the confusion, you are of course right you . Of course you can
have a "fallback HA" configured like for the co-located case.

However, here we are talking about the a case where you may have a default HA
configured, which the MN is not registered to, but the HA receives a
de-registertion request from the MN anyway. So, what does the RFC3220 (MIPv4)
say the HA should do in this case, since the user would already be non-existent
in the HA's routing tables / internal state information ?!

/Tony