Subject: [AAA-WG]: Mobile IP Extension

From: Pat Calhoun <[email-masked]>
Date: Tue, 13 Mar 2001 12:22:18 -0800 (PST)

All,

It has come to my attention that the following changes are required in the
Mobile IP extension.

1. Support for the Filter-Rule

	I have been informed that there is demand for downloading Filter Rules,
	as defined in the NASREQ extension to Foreign Agents, and Home Agents
	(so in the AMA and HAR, respectively). However, the Filter-Rule AVP is
	defined in the NASREQ extension. So, we have the following options:

	a) Move the Filter-Rule AVP to the base protocol
	b) Redefine another Filter-Ruls AVP in the mobile IP extension
	c) Simply have the Mobile IP extension refer to the Filter-Rule AVP
	   from the NASREQ extension, or
	d) Create a new extension that ONLY defines the Filter-Rules, but no
	   command code (so I am not even sure that it would require an 
	   Extension-Id).

	Does anyone have an opinion on the best approach?

2. Support for co-located Mobile Nodes

	The Mobile IP extension currently requires the Foreign Agent to contact
	the AAA infrastructure. However, when a mobile node is co-located there
	is no Foreign Agent, and therefore the Home Agent would be the 
	instigator of the AMR to the AAAH. I propose keeping the AMR/AMA messages
	for this purpose, but would create a new Feature-Vector value that would
	indicate this was a co-located mobile node.

Any comments?

PatC

---

From: David Spence <[email-masked]>
Date: Wed, 14 Mar 2001 13:35:21 -0500

See comments interspersed below.

>         a) Move the Filter-Rule AVP to the base protocol

And after this starts down the standards track and someone else discovers an
attribute in one extension that would be useful in another extension, we
would stop the standards train, add yet another AVP to the base protocol and
restart the train?  So I don't like "a)" because it doesn't provide a good
model for how to handle this kind of problem in the future.

>         b) Redefine another Filter-Ruls AVP in the mobile IP extension

I kinda like the concept of reusability myself -- define Filter-Rule AVP
once and reuse it wherever it's needed.

>            from the NASREQ extension, or

I think that would work.  It does mean you have to download more RFCs to get
everything you need, but it works.

>            command code (so I am not even sure that it would require an

Sounds like a great way to multiply the number of RFCs required to define
Diameter:

"This RFC defines AVPs common to both the NASREQ and Mobile IP extensions."

"This RFC defines AVPs common to both the NASREQ and Chicken Fryer
extensions."

"This RFC defines AVPs common to both the Mobile IP and Chicken Fryer
extensions."

>         Does anyone have an opinion on the best approach?

So far, I guess I like "c)".  Are there any other ideas?

>... 

-- 
David Spence                            email: [email-masked]
Interlink Networks, Inc.                phone: (734) 821-1203
775 Technology Drive, Suite 200         fax:   (734) 821-1235
Ann Arbor, MI 48108           
U.S.A.

---

From: "John Alayari" <[email-masked]>
Date: Wed, 14 Mar 2001 11:21:41 -0800

>	indicate this was a co-located mobile node.

Pat,

I agree with using a bit in the MIP-Feature-Vector avp. However, all 8 bits
are allocated and we need to extend it to 16 bits or more. BTW, in the
Mobile IP extension, do we need a section to describe co-location scenario?

John Alayari

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 14 Mar 2001 11:54:32 -0800 (PST)

> Mobile IP extension, do we need a section to describe co-location scenario?

The Feature-Vector avp is of type Unsigned32, and yes we section will be
necessary to describe the expected behavior.

PatC

---

From: "Fredrik Johansson" <[email-masked]>
Date: Fri, 16 Mar 2001 02:17:45 +0100

I like the reusablility, but here is a problem with reusing the filter rules
as defined in NASREQ since they specified the order of evaluation. FreeBSD
uses in order and first match terminates evaluation, however, in OpenBSD the
filters are evaluated in order and the last match determines what to do with
the packet (unless you add 'quick' to the rule)

I'm not sure if we should try to come up with a general filter rule that can
be used no matter what implementation, and perhaps specify some new AVP that
takes care of the differences.

Or perhaps, the way to go is to define a new set of AVPs which would make it
easy for the implementation to determine if it is supported or not. There
should not be a case where a subset of the received AVPs are supported, it
would make it hard to determine what to do with the ones that are
understood.

A third way could be to keep the filter rules as they are today, and if
someone would like to support another implementation they will make it
vendor specific.

/Fredrik

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On
>Behalf Of David Spence
>Sent: den 14 mars 2001 19:35
>To: Pat Calhoun
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: [diameter] Re: [AAA-WG]: Mobile IP Extension
>
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 15 Mar 2001 19:55:44 -0800

Just a question.

Can you provide some background on what constitutes an extension?
What, for example, distinguishes an extension from something in the
base protocol?

Also, how is the DIAMETER extensibility model different from the
RADIUS model? Can a DIAMETER server send an arbitrary AVP to a 
DIAMETER client, as can be done in RADIUS? Or is it more like
RPC, where you have a way of transmitting arbitrary data over
the wire (XDR), but you need to have the same functions
implemented on both client and server?

---

From: Barney Wolff <[email-masked]>
Date: Fri, 16 Mar 2001 00:49:59 -0500

We MUST NOT leave the order of evaluation unspecified.  Personally
I think anything but first match counts is crazy, but whatever we
do, we cannot leave it to the creativity of the enforcement point.
How could any inter-domain or inter-vendor scenario be viable, if
that were so?  A NAS that runs on last-match can reverse the order
of the rules before evaluation, but the home server cannot and
should not know the style of the NAS, so must issue the rules in
a standardized form.  As a simple example, take the rules
  deny tcp eq 6000
  permit tcp ge 1024

In all of AAA, semantics is far more important than syntax.  I'd
generalize that to any protocol design, and in fact to all of Life.

Barney Wolff

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 16 Mar 2001 06:53:55 -0800 (PST)

I *completely* agree with Barney. 

If you are writing to an implementation that does not meet the AAA
requirements, then it is up to the developer to do what it takes to make it
work. 

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 16 Mar 2001 06:58:39 -0800 (PST)

> What, for example, distinguishes an extension from something in the

Historically, an extension consists of at least one command code. I realize my
e-mail was off the wall, but I listed it as an option. Taking that option, of
course, would lead us in unchartered Diameter territory...

> implemented on both client and server? 

A mix of both.

During the DRI, you discovery your peer's capabilities, and don't send any
messages whose extension wasn't advertised. Each message has a list of AVPs
that MUST, and SHOULD, be present. Of course, one can always add some other
arbitrary AVP in the message, and hope that the other end supports it, as in
RADIUS, and there isn't much we can do to protect against that, IMHO.

However, if the Mobile IP extension does include the Filter-Rule AVP from the
NASREQ extension, then people will expect it to be present, and we will not
get in any trouble. However, if it isn't explicitely stated in the extension,
chances are it will be unrecognized by implementations that do not support the
NASREQ extension.

Hope this helps,

PatC

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 16 Mar 2001 11:43:36 -0800

>course, would lead us in unchartered Diameter territory...

OK, this makes sense. Extensions are created only to support new message
types,
not just new AVPs. I'd recommend that these paragraphs be put in the spec
somewhere to make sure this is clear.

>RADIUS, and there isn't much we can do to protect against that, IMHO.

OK. As a result of this, I would say that any AVP that is listed as a MUST,
SHOULD
or MAY within multiple extensions should go into the Base Protocol. Also,
for
RADIUS interoperability, I would suggest that any AVP or message that is
defined in
RFC 2865-2869 should also go into the base protocol. That way any DIAMETER
implementation can be guaranteed to be able to gateway RADIUS messages, as
noted in the requirements. This means that Accounting and NASREQ extensions
need to be mandatory to implement.

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 16 Mar 2001 11:52:01 -0800 (PST)

> somewhere to make sure this is clear.

ok, will do.

> need to be mandatory to implement.

hmm... well NASREQ has much more than just RADIUS, it has a whole bunch of
Diamter-only AVPs, and mandating those would be a mistake, IMHO.

Perhaps it is necessary to split up the NASREQ extension into two. One
containing all of the RADIUS attributes, and the other containing the
Diameter-only attributes.

Or perhaps just a paragraph in the base that states that a Diameter
implementation MUST support all attributes in RFC 2865-2869. However, both of
the above is a red herring, since the initial Diameter deployment will be for
Mobile IP, and they don't even need any RADIUS compatibility.

PatC

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 16 Mar 2001 18:36:29 -0800

>Diamter-only AVPs, and mandating those would be a mistake, IMHO.

What is the downside of including these attributes in the base protocol?
Assuming that the additional attributes require no new server code,
then we're just talking about shipping some additional dictionary
entries, right? 

I suppose that there is now the risk of introducing semantic errors that
wouldn't exist otherwise. For example, a Diameter server sending
a dialup-only attribute to a Mobile-IP enabled NAS. However,  
if you send those attributes to a client that doesn't
understand them, you get an error message back, so nothing bad
happens. 

>since the initial Diameter deployment will be for Mobile IP, and they 
>don't even need any RADIUS compatibility.

Are we saying that the ability to gateway to RADIUS is not a requirement
of the base protocol? I think that this is an important decision to make.

---

From: "Fredrik Johansson" <[email-masked]>
Date: Mon, 19 Mar 2001 22:18:27 +0100

Of course we can not leave the evaluation order unspecified. And I agree
that the semantics are more important than the syntax. What I don't like is
to not have a framework that allows for new options to be added (or at least
enables the use of the options available today).

What about making the <Filter-Rule AVP> into a grouped avp? Call it <Filter
AVP> which contains a <Filter-Rule AVP> and something like a <Filter-Option
AVP> which is a uint32 with flags for options like keep state, quick ...

I also think that one should have the option of grouping filters, i.e.
perhaps a <Filter-Group AVP>, which contains all <Filter AVPs> within a
certain group.

If it is true that one can just reverse the order of evaluation (would like
to check some real examples) we can leave it as it is today, or perhaps
indicate the order in the Filter-Option Avp.

Comments?!?

/Fredrik

>From: Barney Wolff [mailto:[email-masked]]
>Sent: den 16 mars 2001 06:50
>To: Fredrik Johansson
>Cc: David Spence; Pat Calhoun; [email-masked]; [email-masked]
>Subject: Re: [diameter] Re: [AAA-WG]: Mobile IP Extension
>
>

---

From: Barney Wolff <[email-masked]>
Date: Mon, 19 Mar 2001 18:21:06 -0500

The filter capability is a compromise.  On one side, we want to be
able to express powerful filtering.  On the other, we don't want
to seduce the server into specifying filtering that the NAS (or
other enforcement point) does not implement, as we then get into
the very messy question of what the NAS should do if it does not
implement a particular rule.  I made a conscious choice NOT
to include keep-state, but that's certainly a debatable issue.

Said another way, I hoped to encourage NAS vendors to implement
better filtering but not ask for so much that they would decline.

Barney

---

From: "Fredrik Johansson" <[email-masked]>
Date: Tue, 20 Mar 2001 19:57:22 +0100

Ok, the filter capability is a compromise, and all implementations will
certainly not support all possible options, but to remove the options of one
of the most commonly used freewares is something that can be discussed. I
don't know much about how filters are used in a NAS, but I can only assume
that that was a valid choise considering it is only specified for use with
NASREQ. However, as more extensions (MIP) are looking at using filter rules,
I believe that it would be nice to have a common set rules that can be
reused. The question is where they should be located (NASREQ, MIP, BASE, or
stand alone) and the format and options to include.

The problem with a NAS (or other enforcement point) that does not support an
option can be solved by having the NAS responde with a failed AVP idicating
what options that was not supported. The server can then try to send another
set of rules.

Another thing is that AAA server usually know from what kind of enforcement
point it is receiving the request from, i.e. it can decide on what kind of
filters to send to it. This way it is easy to configure not to send keep
state to a NAS.

/Fredrik

>Sent: den 20 mars 2001 00:21
>To: Fredrik Johansson
>Cc: Barney Wolff; David Spence; Pat Calhoun; [email-masked];
>[email-masked]

---

From: Barney Wolff <[email-masked]>
Date: Tue, 20 Mar 2001 15:41:08 -0500

The point of the compromise is to *avoid* the situation where some
rule types are not supported by a popular implementation.  If we
were willing to make the server deal with negotiation of rule sets
we could have defined an infinitely powerful filter capability.
IMHO that would be a very bad idea.  Diameter is a security protocol,
and simplicity is your friend.  (Yes I know, "simplicity" and
"Diameter" in the same sentence approaches parody.  But we shouldn't
make it even worse.)

Regards,
Barney

On Tue, Mar 20, 2001 at 07:57:22PM +0100, Fredrik Johansson wrote:
> of the most commonly used freewares is something that can be discussed. ...