Subject: [nemo] AAA and NEMO

From: Alper Yegin <[email-masked]>
Date: Wed, 12 Feb 2003 17:40:16 -0800

Hello,

Here is an attempt to initiate discussions around AAA and NEMO
interaction. Please provide comments....

From network access authentication and authorization perspective,
a NEMO network has two type of interactions. One is between the MR and the
its point of atttachment to the Internet. The other is between the
MNN and the NEMO. These can be viewed as separate and independent
from each other. MR can change its point of attachment any time, and this
requires new authentication and authorization for the MR. But this should
not require new auth/authz for the MNNs currently attached to the network.
Similarly, MNNs can come and go, but this should not necessarily require
auth/authz actions between the MR and its point of atttachment to the
Internet. The current AAA toolset should serve the needs (Radius, Diameter,
PANA, 802.1x, etc.)

In a simple mobile IP case, MN changes its point of attachment
hence goes through full AAA with the new access network. But with
the NEMO model, there is no need to do auth/authz of MNNs when the MR
moves around. How does accounting get affected by this?

A movement of MR might change the charging parameters that
MR is subject to. If such fluctuations are not to be passed down to the
MNNs, the current model of separate AAA stays valid. So, the MNNs can assume
that the billing parameters stay fixed between subsequent auth/authz.
Or, another assumption can be, MNNs accept any such fluctuations without
explicit notification from the NEMO network. Are these assumptions
acceptable? If not, then extensions to current AAA mechanisms might be
needed.

Thoughts?

alper

---

From: Greg Daley <[email-masked]>
Date: Thu, 13 Feb 2003 13:16:41 +1100

Hi Alper.

Thanks for starting this one up.

> not require new auth/authz for the MNNs currently attached to the network.

I think that this is implicit in systems which do not route-optimize MNN
traffic direct from the NEMO.

When RO is in place for MNNs though, it may depend on how addresses
are being allocated to the MNNs from the access network.

Proving the identities of MNNs may be necessary if these devices are
required to interact with the router on the MR's link in order to gain
the address or (Secure)ND capability for the addresses. Then again,
since any ND operations are likely to be proxied, the MR could do this
too, with its own identity or the MNN's.

If the MR's CoA is the only address visible to the fixed network
access router, it really should look similar to a mobile-ip MN.

> moves around. How does accounting get affected by this?

I agree that the principle issue is that the MR does AAA with the Access
Network.   Since the Access Net will not have explicit NEMO support in
most cases, I would try to maintain (at best) fixed-network requirements
or (at worst) mobile-ip like requirements for the MR on the access link.

Not that I think that mobile-ip like requirements are bad, but we can't
expect more from the fixed networks.

NEMOs may provide indication that they are Networks, in a mobile-ip
compatible way, which could allow networks to support them better, or
bar access because of service policy and security conerns about evil
NEMOs ;).

> acceptable? If not, then extensions to current AAA mechanisms might be

I think that the relationship between the billing of MR and that of
billing the MN may be re-negotiable through the AAA (MNN-MR) system.
If the MNN desires further service, and costs change, then it may
just be that negotiations for payment break down and the MNN doesn't
receive service (or doesn't receive RO service).
Both devices would be aware of the change, and would react
appropriately.  If a NEMOSP wasn't playing nicely, I'm pretty sure that
people could find an alternative, or turn off their connection!
Of course this issue applies only to those nodes sophisticated enough
to negotiate either NEMO or AAA paramters. Some networks will have
nodes which can't, or may find this sort of issue unnecessary.

---

From: Takeshi TANAKA <[email-masked]>
Date: Thu, 13 Feb 2003 12:42:11 +0900

Hi, Alper

It is a good starting point for discussion about NEMO and AAA.

I think usage scenario of NEMO is important when considering NEMO and AAA.
I assume this discussion is based on the scenario that MR is providing 
an ISP service.

On Wed, 12 Feb 2003 17:40:16 -0800 

> Internet. The current AAA toolset should serve the needs (Radius, Diameter,
I agree.

As far as access network does not identify the resources(an IP address) 
that it provides to MR from the resources it provides to an ipv6 node, 
current AAA mechanism should serve.

> acceptable? If not, then extensions to current AAA mechanisms might be
I remember one of the requirements for basic support is
  "routing(binding) management operation must be transparent to MNN".
According to this, it is preferable that NEMO isp network does not 
change its billing policy, either when the billing policy of access 
network of MR changes, but, that may be what NEMO isp decides.

I think AAA mechanism should be able to have the scheme that is capable 
of change of billing policy at anytime with/without letting MNN know.

Regards,
Takeshi

---

From: William D Ivancic <[email-masked]>
Date: Wed, 12 Feb 2003 23:14:02 -0500

At 05:40 PM 2/12/2003 -0800, Alper Yegin wrote:

>MNN and the NEMO..... So, the MNNs can assume
>acceptable?

I believe such assumptions are acceptable.

I also believe that many and perhaps most NEMOs will be mobile networks 
that are part of corporate intranets.  Thus, they will very likely be force 
back through the corporate firewall.

=======================================
Will Ivancic
NASA Glenn Research Center
21000 Brookpark Road    MS 54-5
Cleveland, Ohio  44135
Phone +1 (216)433-3494
Fax +1 (216) 433-8705
Yahoo Instant Messenger  ID: ivancic
http://roland.grc.nasa.gov/~ivancic

---

From: Alexandru Petrescu<[email-masked]>
Date: Thu, 13 Feb 2003 07:51:42 +0100

Alper Yegin wrote:
> moves around.

Also, there's no need for MNN to re-do auth/authz when MNN moves 
inside the same mobile network, of the same MR, right?

-- 
Message Classification: GBU

---

From: Christophe Janneteau<[email-masked]>
Date: Thu, 13 Feb 2003 10:13:24 +0100

Hi all,

About AAA...

> > Internet. The current AAA toolset should serve the needs (Radius, Diameter,

I agree too...
Just as a side comment I would like to note that, in the general case
where the NEMO does not host its own internal AAA infrastucture (i.e.
AAA server), auth/authz for VMN entering the NEMO will require
signalling to "cross the Internet" two times (NEMO at its current
location -> NEMO's Home AAA server -> VMN's Home AAA server) due to the
NEMO's current location potentially far from its Home network. This is a
different with a regular mobile IP node where the internet will
generally be crossed only once.

Similarly, if the VMN moves within the NEMO from one AR1 to AR2,
re-auth/re-authz at the new AR2 may takes more time if the NEMO's home
AAA server is to be contacted...

So AAA performance in the NEMO case may be worse than for the simple
Mobile-IP case...

> > that the billing parameters stay fixed between subsequent auth/authz.

I think this chaging or not the charging of VMN is a policy decision to
be taken by the NEMO (MR). In scenarios where the NEMO (serving as ISP
to VMN) is expected to pay more to maintain it connection to the
infrastucture it may want to charge VMN a bit more...
So I think AAA mechanisms should be able to address re-negociation of
charging...to be triggered by the NEMO. Is this a new NEMO-specific
requirement? Is this already supported by AAA?

Of course, there will be other NEMO scenarios where billing will not be
considered (I hope:)

Thanks
Christophe

---

From: Alper Yegin <[email-masked]>
Date: Thu, 13 Feb 2003 11:26:08 -0800

Hi Alexandru,

> inside the same mobile network, of the same MR, right?

No, actually most probably it'd need that. In an environment where
auth/authz is required for basic network access, it should take
place each time MNN changes its point of attachment. Maybe a
subsequent auth/authz in the same NEMO might  take a different form (i.e.,
some optimizations are possible). But not requiring auth/authz from a
MNN that claims it was already granted access in another part of the NEMO
opens up security holes.

alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 13 Feb 2003 11:35:53 -0800

Hello Christophe,

> generally be crossed only once.

If the NEMO wants to authenticate the VMN, I'm not sure why the AAA
traffic needs to go through NEMO's Home AAA server. It can directly
go to VMN's Home AAA server. Maybe the accounting records are
collected at the NEMO's Home AAA server at the end of the day, but
this shouldn't be per VMN authentication.

> requirement? Is this already supported by AAA?

I'm afraid this might boil down to the NEMO initiating a new auth/authz with
the new charging parameters with every one of the MNNs... :( This might
not require a AAA backend interaction, as NEMO already trust the MNN.
So, some local-trust that was established after the latest (or initial)
auth/authz can be utilized.

> Of course, there will be other NEMO scenarios where billing will not be

And even auth/authz. E.g.: public (free) networks... NEMO should work there
too :)

alper

---

From: Alexandru Petrescu<[email-masked]>
Date: Thu, 13 Feb 2003 23:17:30 +0100

Alper Yegin wrote:
>>> hence goes through full AAA with the new access network. But
>>> with the NEMO model, there is no need to do auth/authz of MNNs
>>> when the MR moves around.
>> 
> subsequent auth/authz in the same NEMO might  take a different form
> (i.e., some optimizations are possible). But not requiring
> auth/authz from MNN that claims it was already granted access in
> another part of the NEMO opens up security holes.

Yes, exactly, that was more like an optimization issue.  MNN would 
basically do auth/authz requests each time it changes its attachment 
point to avoid security risks.

---

From: Alexandru Petrescu<[email-masked]>
Date: Fri, 14 Feb 2003 01:57:00 +0100

> interaction. Please provide comments....

Here's a short remark, thank you for starting this up.

> Internet. The current AAA toolset should serve the needs (Radius, Diameter,

This picture looks very right.  If it could fit in the "nested" cases, 
it would be even better, in case that the "nested mobile networks" 
requirement still has validity.

For example, consider one mobile network 1 attaching to fixed access 
system.  Then mobile network 2 attaches to mobile network 1.  Then MNN 
attaches to mobile network 2.  Consider at this point that everything 
is authenticated/authzed to everything.

Now, if the mobile network 1 changes its attachment point (but mobile 
network 2 doesn't), will the MNN get informed about this?  When mobile 
network 1 does its new auth/authz scheme, will it declare it has the 
visit of the MNN which is deep beneath it?  Will the MNN be aware of 
this movement of the top mobile network 1? (I mean aware in terms of 
auth/authz.)

Maybe I don't have a clear picture about how this could work, but 
maybe you have.  Again, I am in total agreement of the above paragraph 
where you describe the two types of auth/authz (inside and outside). 
I even suggest we have that paragraph somewhere in the requirements, 
if possible.

---

From: Alper Yegin <[email-masked]>
Date: Thu, 13 Feb 2003 16:34:15 -0800

> network 2 doesn't), will the MNN get informed about this?

(putting the billing issue aside) I don't think MNN needs to get
informed about this. MNN gets its service from network2,
and it should not care where network2 or anyone up the chain gets
their access service from. But of course MNN should have sufficient
trust in the network1 that it won't drag MNN into unsecure corners
of the Internet.
And, this is  like the fixed ISP case. If your local ISP changes its
backbone ISP, it doesn't notify you.

> When mobile 
> visit of the MNN which is deep beneath it?

With the similar reasoning, I don't think so.

> Will the MNN be aware of

So, to recap: This "transparency" is a good thing. But the problem is, it
hides possible billing parameter changes that are happening up the chain.
In the above example, MR of network1 can be made aware of it as part
of the new AAA interaction. But either:
- MNNs down the chain should be immune to such changes (i.e., fixed rate),
or
- We'd lose the transparency by introducing some accounting exchange
to all MNNs down the chain.  And this in general is undesirable but maybe
unavoidable.

alper

---

From: Takeshi TANAKA <[email-masked]>
Date: Fri, 14 Feb 2003 10:56:08 +0900

On Thu, 13 Feb 2003 16:34:15 -0800 
Alper Yegin <[email-masked]> wrote :

> their access service from. 
I agree.
And vice versa, network1 cares about auth of network2, and does not 
care about auth of MNN by network2.

> But of course MNN should have sufficient
I think, in some scenario, network1 trusts network2, but does not 
trust(know well about) MNN in some scenario.
i.e. network1 trusts network2, but does not know well about MNN that is
trusted by network2.

> to all MNNs down the chain.  And this in general is undesirable but maybe
I think the latter.
But MNN should be notified accounting exchange only from the network 
MNN attached to.

-----------------------------------------------
 Takeshi TANAKA
 R&D center, Corporate Engineering Division, 
 Panasonic Mobile Communications
 e-mail: [email-masked]
 phone: +81-46-840-5494 / fax: +81-46-840-5222
-----------------------------------------------

---

From: Alexandru Petrescu<[email-masked]>
Date: Fri, 14 Feb 2003 04:51:44 +0100

Alper Yegin wrote:
>> For example, consider one mobile network 1 attaching to fixed 
>> access system.  Then mobile network 2 attaches to mobile network 
>> 1.  Then MNN attaches to mobile network 2.  Consider at this 
>> point that everything is authenticated/authzed to everything.
>> 
>> Now, if the mobile network 1 changes its attachment point (but 
>> mobile network 2 doesn't), will the MNN get informed about this?
> 
> informed about this. MNN gets its service from network2, and it 
> should not care where network2 or anyone up the chain gets their 
> access service from. But of course MNN should have sufficient trust
>  in the network1 that it won't drag MNN into unsecure corners of
> the Internet. And, this is  like the fixed ISP case. If your local
> ISP changes its backbone ISP, it doesn't notify you.

Alper, I think I get the main lines of your argumentation, you're right.

Just to say that my local ISP changes its backbone ISP yes, and it's
invisible to me.  But my ISP doesn't do authorization/authntction to
the backbone ISP in the first place either, so the similarity to
mobile networks is not very clear.

---

From: Christophe Janneteau<[email-masked]>
Date: Fri, 14 Feb 2003 09:22:46 +0100

Hi all,

I agree.

Christophe

---

From: Christophe Janneteau<[email-masked]>
Date: Fri, 14 Feb 2003 11:13:14 +0100

Hi Alper,

> this shouldn't be per VMN authentication.

In the above I consider the case where the NEMO is an IP subnet owned
(in AAA terminology) by the NEMO's Home domain (i.e. NEMO does not have
its own internal AAA server). In such a situation the AAA server
managing auth/authz for hosts entering the NEMO will generally be
located within the NEMO's Home infrastructure. Right?
Now when a VMN enters the NEMO (NEMO being either at Home or attached to
a Foreign network and maintaining the bi-directionnal tunnel to its HA),
it must be auth/authz by the owner of the NEMO's subnet...this implies
contacting the NEMO owner's AAA server..in the NEMO's Home
infrastucture. This is because the VMN is actually visiting the
administrative domain the NEMO belongs to. Of course, the AAA server in
NEMO's Home Domain will have to contact the VMN's Home AAA server to
complete the auth/authz procedure. This is regular AAA model I think...
Does this make sense or am I missing something?

Thanks,
Christophe

---

From: Christophe Janneteau<[email-masked]>
Date: Fri, 14 Feb 2003 11:25:59 +0100

Hi again,

> But MNN should be notified accounting exchange only from the network

This is my current understanding...

When MR changes its point of attachement and auth-/authz to the new AP
its own charging parameters may vary (e.g. pay more for the same
resources). In such a case the MR MAY want to propagate this increase of
charge towards its VMN. This is a policy issue, and is similar to the
case of two ISP: ISP2 connecting through ISP1 and ISP1 increasing its
charges.
If the MR decides to propagate the change to VMN, this should naturally
take place through the Home AAA instrastucure the NEMO subnet belongs
to.

Thanks
Christophe

---

From: Alper Yegin <[email-masked]>
Date: Mon, 17 Feb 2003 17:19:03 -0800

Hi Christophe,

> (in AAA terminology) by the NEMO's Home domain

> (i.e. NEMO does not have its own internal AAA server).
right. But it has to have AAA client (in its Network Access Servers),
and it may have some AAA agents (relay or redirect agents).
These AAA agents can help forward the AAA traffic to right AAA server.

> In such a situation the AAA server

The AAA agents in the NEMO can help the AAA traffic be directed to the
VMN's AAA server without going through NEMO's home AAA server.

alper

---

From: Takeshi TANAKA <[email-masked]>
Date: Tue, 18 Feb 2003 12:03:15 +0900

Hi Alper,

On Mon, 17 Feb 2003 17:19:03 -0800 

> VMN's AAA server without going through NEMO's home AAA server.
I think it depends on AAA policy of AAA agent on the NEMO.

AAA traffic from the AAA agent(should be AAA client) on the NEMO 
will be directed to the VMN's AAA server if the agent has policy 
to proxy it to VMN's AAA server.
The traffic from the agent will go through NEMO's home AAA server
if the agent has AAA policy only with NEMO's home AAA server and 
NEMO's home AAA server has AAA policy to proxy it to VMN's AAA server.

But I think the AAA agent on the NEMO has to process AAA traffic 
in the same way as while the NEMO is at home.

Regards,
Takeshi

---

From: Alper Yegin <[email-masked]>
Date: Wed, 19 Feb 2003 01:32:15 -0800

Hello,

> I think it depends on AAA policy of AAA agent on the NEMO.

Yes it does. My comment was in response to Christophe's message:

So, it doesn't "have to" cross the Internet twice.
And if the right policy is not used, even Mobile IP with roaming would incur
the same sub-optimal path for AAA authentication. This is a
deployment issue.

alper

---

From: Chan-Wah Ng <[email-masked]>
Date: 21 Feb 2003 11:24:32 +0800

Hello Alper and the rest,

Pardon my late response, I was trying to catch up with the mailing list
after a holiday.

Allow me to summarize from what I have read thus far.  There are two
main area of AAA discussions here:

(1) VMN moving with a mobile network.

I think the issue is pretty much settled : VMN is required to perform
auth/authz whenever it change its point of attachment.  However, it
might be an interesting research problem to see if there are ways to
speed up the auth/authz porcess within the current AAA infrastructure,
gconsidering the fact that auth/authz of VMN in a mobile network would
typically require, as previous posts stated, crossing the Internet
twice.

(2) MR chaning its point of attachment.

The issue is whether MNNs need to be notified (or even auth/authz need
to be carried out) when the MR they attched to changes its point of
attachment to the Internet.  

Reason for not notifying the MNNs is simple: it violates the
transparency principle.

Reason for notifying the MNNs: there is a policy/accounting change when
MR changes its point of attachment.

My personal view on this is that the service provide of the MR should
have factored the possible change of policies under normal operation of
the MR and provide a consistent policy to VMNs that are using the MR's
service.  Does that make sense? 

Anyway, this scenario is actually described in the AAA Usage Scenarios
Draft (draft-ng-nemo-aaa-use-00.txt).  It is great to discuss this
further and hopefully the group can reach a consensus on the above two
issues so that I can update the draft.

Comments?

-- 
Chan-Wah Ng <[email-masked]>
Panasonic Singapore Laboratories

---

From: Alper Yegin <[email-masked]>
Date: Fri, 21 Feb 2003 15:53:36 -0800

Hello Chan-Wah,

Just a quick note...

> typically require, as previous posts stated, crossing the Internet

I hope we agreed that the nature of NEMO does not necessarily create such
sub-optimal auth/authz process. The potential optimization (i.e, fast
re-authentication) should be the same as what people are attempting
for fixed access networks as well. Any roaming client can take advantage of
such optimizations, regardless of whether their access network is also
roaming. But because of the increased number of "moving parts", these
optimizations' benefits are amplified in the NEMO case, I think.

alper

---

From: Christophe Janneteau<[email-masked]>
Date: Sat, 22 Feb 2003 18:48:58 +0100

Hi Alper and Chan-Wah,

> optimizations' benefits are amplified in the NEMO case, I think.

I agree, fast re-auth mechanisms are even more critical in the NEMO
context that in the fixed context...

Christophe