Subject: [MOBILE-IP] RFC-2006 MIB upgrade is required

From: Ravindra Rathi <[email-masked]>
Date: Fri, 3 Nov 2000 20:22:53 +0530

Hello all,
        At present  tables in RFC-2006 MIB are indexed by ipaddress with
the assumption that each mobile node(MN) is uniquely going to be
identified by the
ipaddress. Now since MN can be identified by network access identifier
(NAI) and
ipaddress assigned to MN can change across registrations with
home-agent,
tables in MIB need to support NAI to reflect correct information.

Thanks,
Rathi

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 3 Nov 2000 07:32:19 -0800

Hello Rathi,

By the time the MIB stuff needs to be maintained,
the mobile node DOES have an IP address.

I think that should make it O.K.

Regards,
Charlie P.

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 3 Nov 2000 07:41:01 -0800

> the mobile node DOES have an IP address.

Correct. However, if one wants to be able to manage a particular mobile node,
the only static information is the NAI. So, the current MIB forces one to scan
through all Mobile Node entries looking specifically for the NAI.

> I think that should make it O.K.

Perhaps, as specified it is very tedious.

PatC

---

From: Kent Leung <[email-masked]>
Date: Fri, 3 Nov 2000 08:40:28 -0800

>through all Mobile Node entries looking specifically for the NAI.

Yes, the MN is no longer identified by the home address (which may be
dynamically allocated), but its NAI.  So management should be based on NAI
for MNs that use NAI.

Perhaps, since NAI is directly tied to authentication, a higher abstraction
is a Service ID?  A Service ID would map directly to NAI if only one IP
address is allocated to an MN with NAI.  But it's possible in the future to
have same NAI used for authentication for different devices or services on
the same device, which requires individual IP addresses.  In this case each
individual binding has a unique Service ID.  So management of mobility
binding entry may need to be at the Service ID level?

Since we need a new RFC draft to support non-IP address identified MN, we
can aim for extensibility.  Just a thought.

-- Kent --

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 3 Nov 2000 08:51:27 -0800

Hello Pat,

> through all Mobile Node entries looking specifically for the NAI.

Which node do you mean that is managing the particular mobile node?

- If it's AAAH, then I think there's no problem, except insofar as
  AAAH might want to be the SNMP master to acquire data from HA.

- If it's HA, then the HA that allows this feature "should"
  create pointers between its NAI indexed data and its IP
  addressed data.

- If it's FA, then I am surprised.

- If it's MN, then I am really surprised.

Furthermore, I would suggest that NAI-oriented MIB data
doesn't belong in the Mobile IP MIB.  NAIs are not network
layer things.  Maybe there needs to be "extension-specific"
MIB fields for the AAA MIB.  Errr.... is there such a thing
as an AAA MIB?  How about a Mobile IP extension MIB for AAA?

Regards,
Charlie P.

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 3 Nov 2000 11:03:21 -0800

> Which node do you mean that is managing the particular mobile node?
The HA. When walking through the various MIB entries, the NAI is not even
present, so it would be rather difficult to "identify" a Mobile Node. Adding
an NAI SHOULD be a trivial change.

> Maybe there needs to be "extension-specific"

The AAA Design Team does have DIAMETER MIBs on its plate, and I do agree with
your statement.

PatC

---

From: Ravindra Rathi <[email-masked]>
Date: Sun, 5 Nov 2000 17:10:47 +0530

Hello Charlie,
        I will explain my point by taking specfic examples of few tables in
MIB.

1. haCounterTable
-------------------
 Description of table says  "A table containing registration statistics for
all
 mobile nodes authorized to use this home agent."
            If mobile node (MN) dynamically gets ipaddress based on NAI, then
there can be more that one entry in the table for the same MN since it is
indexed by home address of MN which can change across registrations.
Essentially in that case information in this table would not reflect
statistics for given MN correctly.

2. mipSecViolationTable
-------------------------
            If there is a security violation from one of the MNs which uses
NAI, then
there will be entry in this table with index being ipaddress of MN.  There can
be two problems here.
    i ) MN might not have got ipaddress yet.
   ii)   The entry  can't really identify the  MN since the  ipaddress is not
tied to particular MN.

3. mipSecAssocTable
----------------------
            Security associations between MNs (which are based on NAI ) and
home agent or  foreign agent  can't be retrieved through this table.

--Rathi

--
Ravindra Rathi
Cisco Systems
"Waterford", #9, Brunton Road
Bangalore-560 001
Tel: +91-80-532 1300 - 1306 x: 6315

---

From: Charlie Perkins <[email-masked]>
Date: Sun, 5 Nov 2000 14:39:04 -0800

Hello Rathi,

Perhaps Mobile IP is not the only protocol that has to deal
with identifying nodes that can have dynamically allocated
IP addresses.  Is there a lesson we can learn from other
protocols?

I think it is good to keep in mind that the NAI may not be
sufficient, since a mobile node may eventually use other ways
to identify itself that we don't know about yet.

Regards,
Charlie P.