Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Wed, 4 Oct 2000 16:47:26 +0100

I guess this can't be done...

Is this the authors' understanding too, by now?

> > > -----Original Message-----
> > > From: [email-masked] [SMTP:[email-masked]]
> > > Sent: Wednesday, October 04, 2000 7:19 AM
> > > To:   [email-masked]
> > > Subject:      I-D ACTION:draft-jaseem-rap-cops-mip-00.txt
> > >
> > > To: IETF-Announce: ;
> > > CC: [email-masked]
> > > From: [email-masked]
> > > Reply-to: [email-masked]
> > > Subject: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt
> > > Date: Wed, 04 Oct 2000 06:54:46 -0400
> > > Sender: [email-masked]
> > >
> > > --NextPart
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > directories.
> > >
> > >
> > >       Title           : COPS usage for Mobile IP (MIP)
> > >       Author(s)       : M. Jaseemuddin, A. Lakas
> > >       Filename        : draft-jaseem-rap-cops-mip-00.txt
> > >       Pages           : 14
> > >       Date            : 03-Oct-00
> > >
> > > Mobile IP is a protocol that is used to achieve transparent routing
> > > of IP packets to a mobile node. A mobile node obtains a care-of-
> > > address in the foreign network and registers that address with the
> > > home agent. The home agent as well as the foreign agent can apply
> > > policies to the mobile node registration. This draft defines COPS
> > > [1] usage for Mobile IPv4 [2]. It describes how COPS is used to
> > > control Mobile IP registration based on policies. It defines the
> > > interactions between the PEP and the PDP to handle Mobile IP
> > > registration messages. It also provides a guideline for mobility
> > > agents on how to use this COPS client with regards to the
> > > registration messages.
> > >
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-jaseem-rap-cops-mip-00.txt
> > >
> > > Internet-Drafts are also available by anonymous FTP. Login with the
> > > username
> > > "anonymous" and a password of your e-mail address. After logging in,
> > > type "cd internet-drafts" and then
> > >       "get draft-jaseem-rap-cops-mip-00.txt".
> > >
> > > A list of Internet-Drafts directories can be found in
> > > http://www.ietf.org/shadow.html
> > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> > >
> > > Internet-Drafts can also be obtained by e-mail.
> > >
> > > Send a message to:
> > >       [email-masked].
> > > In the body type:
> > >       "FILE /internet-drafts/draft-jaseem-rap-cops-mip-00.txt".
> > >
> > > NOTE: The mail server at ietf.org can return the document in
> > >       MIME-encoded form by using the "mpack" utility.  To use this
> > >       feature, insert the command "ENCODING mime" before the "FILE"
> > >       command.  To decode the response(s), you will need "munpack" or
> > >       a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
> > >       exhibit different behavior, especially when dealing with
> > >       "multipart" MIME messages (i.e. documents which have been split
> > >       up into multiple messages), so check your local documentation on
> > >       how to manipulate these messages.
> > >
> > >
> > > Below is the data which will enable a MIME compliant mail reader
> > > implementation to automatically retrieve the ASCII version of the
> > > Internet-Draft.
> > >
> > >
> > > --NextPart
> > > Content-Type: Multipart/Alternative; Boundary="OtherAccess"
> > >
> > > --OtherAccess
> > > Content-Type: Message/External-body;
> > >       access-type="mail-server";
> > >       server="[email-masked]"
> > >
> > > Content-Type: text/plain
> > > Content-ID:   <[email-masked]>
> > >
> > > ENCODING mime
> > > FILE /internet-drafts/draft-jaseem-rap-cops-mip-00.txt
> > >
> > > --OtherAccess
> > > Content-Type: Message/External-body;
> > >       name="draft-jaseem-rap-cops-mip-00.txt";
> > >       site="ftp.ietf.org";
> > >       access-type="anon-ftp";
> > >       directory="internet-drafts"
> > >
> > >
> > > --OtherAccess--
> > >
> > > --NextPart--
>

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Wed, 4 Oct 2000 19:38:57 +0100

>     I know this is going to get dinged by many of the people I work with
> (on
> this list, and in the office), but is there some reason the authors can't
> have
> an individual submission for an informational RFC?  RFC2356 comes to mind
> (use
> of SKIP FW traversal in Mobile IP), published by the mobile ip working
> group
> in June 1998, after the decision of the IPSec WG (and Jeff Schiller) for
> ISAKMP/Oakley as the IPSec protocol of choice.  If the authors want to
> work on
> this, it doesn't have to be an official working group document (hence the
> name
> d-jaseem-..., not d-i-mip-...) to get some review from mobile ip WG
> members
> willing to read it (if any, and presuming it works).  If the authors want
> to
> move it to anything more than informational, however, it seems likely to
> be
> blocked by the IESG...
>
>
Your line of reasoning is somewhat valid in general terms to me.

However, this intention should have been clear either from the
posting from the authors or from the abstract.

Neither guides us in that direction. Nor mention of the
currently selected approach is anywhere in the document.

Of course, if they authors to go for an individual info RFC, they can try,
but I would claim that since COPS is standards track too,
things may not be as similar to SKIP firewall traversal as it may look like
:).

Let's wait and see what the authors want to tell us (if they are on this ML)

alessio

---

From: Abderrahmane Lakas <[email-masked]>
Date: Wed, 4 Oct 2000 14:29:24 -0400

The comments to this draft are understood and well taken. Let me just
clarify that our intent (authors) is neither to use COPS as a protocol for
AAA, nor to open up any AAA-COPS discussion on whatever aspects of
management.

COPS is used here for non-AAA related aspects of Mobile IP. In our draft, we
propose a way to notify the PDP with the presence of MN for which
policy-related configurations may be applied. COPS looks at the relevant
extensions in the registration messages in order to make policy-related
decisions. The AAA extensions are handled by AAA authority.

We understand that we may not have highlighted it enough in the draft, but
we are not in any way proposing AAA solution for Mobile IP.

Our assumptions here is that AAA handles AAA things, and COPS handles
policy-related things. It's not clear yet for us how both coordinate, but we
assume that the PDP needs to know an MN has attached to the mobility agent,
and policies may need to be applied to it. For example, based on the
received extensions, the PDP may decide to install the MN's QoS profile.
Other extensions that are or will be defined in the future may require some
policy-management through COPS.

Finally, this proposal has merit only if COPS is used for policy management.

- Abderrahmane

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, October 04, 2000 10:07 AM
To: [email-masked]
Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt

Ok, I'll be the first one to reply, and if you don't mind, I'll take off the
white gloves (not that I wear them *that* often).

Why?

The IETF has already decided that network access (and specifically Mobile
IP)
authentication, authorization and accounting is done through the protocol
that
was selected in the AAA WG. COPS was a potential protocol, and did not
succeed.
 So may I ask why you insist on opening up the can of worms all over again?
Hasn't the past 2 years of AAA run around been enough?

Am I missing something obvious? Or are some COPS people refusing to let the
AAA do its work? Or is causing confusion in the marketplace the ultimate
goal?

PatC

> We have submitted a draft defining COPS usage for Mobile IP. The
> announcement is attached below. We will appreciate any comments.
>
> - Muhammad Jaseemuddin
>
readers

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Wed, 4 Oct 2000 20:26:48 +0100

My question is: if some form of policy management will be performed using
COPS, what makes the PEP/PDP interaction inherently different
when mobile IP is used?

I ask this question without having carefully read the draft,
but, if you have time, this could make your proposal's
scope clearer.

thanks

alessio

> ----------
> From:         Abderrahmane Lakas[SMTP:[email-masked]]
> Reply To:     Abderrahmane Lakas
> Sent:         04 October 2000 19:29
> COPS is used here for non-AAA related aspects of Mobile IP. In our draft,
> we propose a way to notify the PDP with the presence of MN for which
> policy-related things. It's not clear yet for us how both coordinate, but
> we assume that the PDP needs to know an MN has attached to the mobility
> agent, and policies may need to be applied to it. For example, based on
> the received extensions, the PDP may decide to install the MN's QoS
> profile. Other extensions that are or will be defined in the future may
> require some policy-management through COPS.
>
> From: [email-masked] [ mailto:[email-masked]]

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Wed, 4 Oct 2000 20:40:13 +0100

In particular, clarifying why you need this would
be helpful...

4. Handling MIP authentication extensions

If the PDP is delegated to perform authentication,
the PEP MUST send the FLO for the registration message
 followed by an extension object, all encapsulated in a client
SI object. The extension object MUST contain all extensions
 including the authentication extension that the PDP is required
to process, in the order they appear in the message.
See section 3.5 in [4] for the ordering and processing requirements
of authentication extensions, and [5] for AAA requirements.
If an authentication fails, the PDP is required to include
the appropriate authentication failure code in the decision message.

> ----------
> From:         Casati, Alessio (Alessio)[SMTP:[email-masked]]
> Reply To:     Casati, Alessio (Alessio)
> Sent:         04 October 2000 20:26

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Thu, 5 Oct 2000 14:29:35 +0100

While I'm waiting for answers,
I'll go further, hoping the backlog won't
increase too much:

It seems to me that in case some policies are related
to QoS, then a QoS client is better suited than a MIP client.
maybe we could define MIP QoS extensions that could be used by
(that is are compatible with) the COPS RSVP client (just as a dumb example).

If instead you are talking about roaming policies, then probably they
could naturally fit within the AAA framework.
Any user profile can also be
downloaded to a PEP (which does not necessarily speak COPS) when
the user registers and as such the home AAA server is queried.
This is somehow consistent with the HSS model...
The envelope of such profiles may
not be COPS. It may be part of the AAA protocol (more usefully, I think)

For other "service specific" policy, again, the MIP extensions
possibly should be defined so that they could be used by the
client for that specific service.

alessio

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Thu, 5 Oct 2000 16:35:20 +0100

>       [MJ]  You are very close to what has motivated us
>
Cool!

> . Yes, we can define some MIP extension for QoS, but where that extension
> will be processed? Most likely at PDP. For that, we need to communicate
> that QoS extension to the PDP. We can do that using COPS-MIP.
>
Or COPS RSVP if we are smart enough to reuse work done by others...

>       I am glad that you mentioned COPS-RSVP. Because, that helps
> understand COPS-MIP as it is analogous to COPS-RSVP. They both use the
> same COPS signaled policy model. However COPS-RSVP is designed to
> understand and handle RSVP objects. In order to handle MIP extensions,  we
> need a new COPS client that understands and handle MIP extensions. That's
> what we think COPS-MIP is for.
>
I would regard COPS MIP as useful as COPS IP. The fact a user is moving
should not
affect policy mechanisms.

>       [MJ]  Yes the roaming policies are most likely handled by AAA
> server, and if the PDP needs information about them, then the PDP can
> communicate with the AAA server. But, whichever mechanisms are used to
> handle roaming policies, should not affect COPS-MIP.
>
If COPS MIP won't exist, as I personally think, this is going to be most
likely.

>       [MJ]  Which client? If you are talking about COPS client, then that
> is COPS-MIP.
>
>
Oh well,

If I talk about host routing, somebody thinks I talking about CIP
If I talk about a COPS client, somebody thinks it is the COPS MIP client...

Please, try not to limit your perspective to the work you have done
(which is pointing out some aspects people could work on, but probably
it is not the best possible solution).

having said that, I'm still waiting some answers from the backlog

(there's one on authentication handling I'm particularly keen on)

Alessio

---

From: Muhammad Jaseemuddin <[email-masked]>
Date: Thu, 5 Oct 2000 10:16:22 -0500

Alessio:

        See my comments in-line.

> From: Casati, Alessio (Alessio) [SMTP:[email-masked]]
> Sent: Thursday, October 05, 2000 9:30 AM
        [MJ]  You are very close to what has motivated us. Yes, we can
define some MIP extension for QoS, but where that extension will be
processed? Most likely at PDP. For that, we need to communicate that QoS
extension to the PDP. We can do that using COPS-MIP.

        I am glad that you mentioned COPS-RSVP. Because, that helps
understand COPS-MIP as it is analogous to COPS-RSVP. They both use the same
COPS signaled policy model. However COPS-RSVP is designed to understand and
handle RSVP objects. In order to handle MIP extensions,  we need a new COPS
client that understands and handle MIP extensions. That's what we think
COPS-MIP is for.

---

From: Muhammad Jaseemuddin <[email-masked]>
Date: Thu, 5 Oct 2000 17:05:28 -0400

Alessio,

 please see my comments in-line.

> Sent: Wednesday, October 04, 2000 3:27 PM
        [MJ]  COPS defines how PEP and PDP interact, but does not define
what they are interacting about. We need a COPS usage that defines the
content of these interactions for mobile IP. I think this point was further
discussed when we had discussed about handling MIP extensions.

---

From: Muhammad Jaseemuddin <[email-masked]>
Date: Thu, 5 Oct 2000 16:03:41 -0500

> Sent: Wednesday, October 04, 2000 2:39 PM
        [MJ]  That depends on the need and the interest of the community.
Discussions in the RAP and Mobile-IP WGs will determine what directions to
take.

---

From: Muhammad Jaseemuddin <[email-masked]>
Date: Thu, 5 Oct 2000 16:10:42 -0500

> From: Casati, Alessio (Alessio) [SMTP:[email-masked]]
> Sent: Thursday, October 05, 2000 11:35 AM
> To:   [email-masked]; Jaseemuddin, Muhammad
> [WDLN2:AN33:EXCH]
> Cc:   Lakas, Abderrahmane [WDLN2:AN33:EXCH]
> Subject:      RE: [MOBILE-IP] FW: I-D
> ACTION:draft-jaseem-rap-cops-mip-00.txt
>
>
>
>
        [MJ]  You can not do it with the current definition of COPS-RSVP,
unless you extend it to handle MIP messages. But then, most likely you'll
end up with some thing like COPS-MIP and thats what we propose.

> affect policy mechanisms.
        [MJ]  I am not sure if I understand what you mean my COPS IP. Anyway
I suggest that we take COPS related discussion to RAP WG where this draft
was submitted. Comments on this draft for MIP related issues are welcome
here.

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Fri, 6 Oct 2000 00:28:02 +0100

> end up with some thing like COPS-MIP and thats what we propose.
I happen to work on a box called GGSN.  We have a RADIUS client that uses
protocol configuration options carried in a protocol called GTP.
These are collected from a PPP authentication phase that runs
between a mobile terminal and a Terminal equipment (basically a phone
and a laptop, to exemplify) and transported across a wireless access
network,
using the radio interface layer 3, and an UMTS backbone, using GTP, to the
GGSN.

Despite the fact this specific radius client interacts with a protocol that
is not
PPP, so far we have not come to the IETF to ask the addition of a RADISU GTP
client.

This tale is to say that independent of the name of the envelope it is
possible
to reuse existing specs.

>       [MJ]  I am not sure if I understand what you mean my COPS IP.
>
BY COPS IP I mean a thing with not much use. It does not exist.
You are then more or less in a situation close to mine, since, so
far, I have not enough elements to understand what COPS MIP is.
An applicability example would help (not based on yet to be defined
extensions). I miss the Compelling reason.

thanks

alessio

---

From: Roberts Philip-qa3445 <[email-masked]>
Date: Fri, 6 Oct 2000 08:50:16 -0500

> ----------
> From:         Steven Glass - Solaris Software
> Reply To:     Steven Glass - Solaris Software
> Sent:         Thursday, October 5, 2000 2:03 AM
> To:   Roberts Philip-qa3445
> Cc:   [email-masked]
> > I thought the AAA working group had already eliminated COPS as a AAA
> > protocol.  If so, please explain why we should be considering COPS in
> MIP?
>
>                               Cheers,
>                                   Steve
Steve,

        I agree 100% with what you've written.  Anyone can submit a personal
draft to this working group and advertise it on this list to get feedback.
My statement was too strong.  I should've asked about the authors' intent
before making the assumptions I made.

Phil

> > > ----------
> > > From:         Muhammad Jaseemuddin
> > > Reply To:     Muhammad Jaseemuddin
> > > Sent:         Wednesday, October 4, 2000 9:10 PM
> > > Subject:      [MOBILE-IP] FW: I-D

---

From: Abderrahmane Lakas <[email-masked]>
Date: Fri, 6 Oct 2000 17:50:28 -0400

Alessio,

First let me say that I agree this section might have introduced some
confusion. It is only meant to capture the requirements of message ordering
for authentication as defined by mobile IP, in case the PDP is involved in
"handling" authentication extensions. The PDP's involvement may be, for
example, in acting as an "attendant" (on behalf of the mobility agent) to
the AAA server before making any policy decision.

As I stated it in my first email, during the writing of this draft, it was
not clear (still is not) for us how AAA would interact with a policy server
to handle common situations. But one should agree that it is hard to see
that section 4 describes any AAA mechanism, or explains the AAA model for
MIP.

- Abderrahmane

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Mon, 9 Oct 2000 10:40:05 +0100

> Abderrahmane;
First off, thanks for your answer.

> confusion. It is only meant to capture the requirements of message
> ordering for authentication as defined by mobile IP, in case the PDP is
> involved in "handling" authentication extensions. The PDP's involvement
> may be, for example, in acting as an "attendant" (on behalf of the
> mobility agent) to the AAA server before making any policy decision.
>
>
I agree with you the current text may have generated some confusion.
I  would suggest, if you have time,
you provide an applicability example, based on current
mobile IP extension, of the proposed COPS-MIP client.
This would be very helpful to fully understand your proposal
and to let the Mobile IP list to evaluate it and provide
useful comments.

> not clear (still is not) for us how AAA would interact with a policy
> server to handle common situations. But one should agree that it is hard
> to see that section 4 describes any AAA mechanism, or explains the AAA
> model for MIP.
>
I agree that the section does not describe an AAA model for MIP.
In fact, the AAA model for MIP is well defined, and this proposal would seem
to
try to comply with it. That's why there are voices expressing the worry
that this would introduce some overlap/conflict with the work currently
ongoing in
the AAA WG (where after two year a protocol has been selected
to base AAA for network access on).

Your text hints to the possibility to use the PDP to perform
authentication. We need to have a clear understanding of this and other
applicability cases of your proposal. You would probably have to
bring to the list cases (or a single case) supporting the necessity of your
proposal. Could you please do that as soon as you have some
leftover time?  I'd wholeheartedly support any proposals of
necessary building blocks to support policy control in conjunction with
mobile IP. I have to understand whether this is one such building block
we are missing.

Thanks

alessio

---

From: Abderrahmane Lakas <[email-masked]>
Date: Wed, 11 Oct 2000 14:05:23 -0400

Alessio,

Consider the actual case of dynamic QoS provisioning: In mobile access
networks, traffic sources are either unknown in advance, or for scalability
reason, the provisioning is done only when the MN registers with the
network. For that the PDP, for example, may use the NAI extension to
retrieve the MN's QoS profile.

But, we should not limit ourselves only to the extensions that are defined.
In general, the mobility raises new questions on how MN and mobility agents
should operate with regards to QoS management and enforcement. COPS-MIP
provides a flexible mechanism through which MIP extensions are exchanged
between the PEP and the PDP, in order to decide the modes in which the MN
and the mobility agents should operate. For example, consider the situation
where the MN moves to a new location (within the same or to a different
foreign network), with active QoS sessions. When registering, MN may express
preferences as to whether the granted QoS be dropped (hard requirements), or
downgraded (adaptive QoS) if the capabilities (wireless link + network) at
the new location are limited.

Hope these examples help understand why we need a new COPS client to handle
policy management for mobile IP.

- Abderrahmane

-----Original Message-----
From: Casati, Alessio (Alessio) [mailto:[email-masked]]
Sent: Monday, October 09, 2000 5:40 AM
To: [email-masked]
Subject: Re: [MOBILE-IP] FW: I-D ACTION:draft-jaseem-rap-cops-mip-00.txt

Thanks

alessio

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Wed, 11 Oct 2000 20:08:58 +0100

Abderrahmane,

> networks, traffic sources are either unknown in advance, or for
> scalability reason, the provisioning is done only when the MN registers
> with the network. For that the PDP, for example, may use the NAI extension
> to retrieve the MN's QoS profile.
>
I guess the (QoS) profile(s) is (are) downloaded from a HSS.
I would say the AAA protocol could work fine as
a carrier of any profile.

It would be nice that all profiles were downloaded
at registration time,
so that there would be no roundtrips
before taking any policy enforcement action.

Now, let's suppose we download the
profile(s) to a PDP, since the device
the user is attached too has storage
limitations (quite unlikely in cellular networks,
but we don't want to limit the scope of
the work to cellular systems).

However, I see queries being directed to
the PDP only if requests are incoming
at times different from the registration.
If so, those requests could include mobile IP
extensions (if they are using mobile IP enhancements????)
defined to comply with COPS-RSVP.
And as such we wouldn't need to use
any new COPS client. Besides, if the
Qos signaling mechanism was RSVP, of course RSVP
client would be used.

If instead the QoS profile is
is installed at registration time,
then the FA could receive it and use it
from the AAA client.
How does it sound???

>  For example, consider the situation where the MN moves to a new location
> (within the same or to a different foreign network), with active QoS
> sessions. When registering, MN may express preferences as to whether the
> granted QoS be dropped (hard requirements), or downgraded (adaptive QoS)
> if the capabilities (wireless link + network) at the new location are
> limited.
>
I would support your proposal if I had in front of me facts,
rather than forward looking statements. I have no clear understanding
of this latter example operation in terms of mobile IP extensions usage
(could RSVP or COPS RSVP be extended instead?)

In fact,  in the face of the previous  scenario
you have presented showing we need COPS-MIP, I was hopefully able to
give a counter-example that makes it not necessary.

Could we say that we may keep
your proposal dormant until we know exactly the scope of its use?
That is we have the extensions we want to use and determined
the best way we want to use them ? This would be my stance for now.

thanks

alessio