Subject: [AAA-WG]: Comments on Base v.3

From: "Fredrik Johansson" <[email-masked]>
Date: Thu, 10 May 2001 17:34:48 +0200

Hi

Here are some comments on the base protocol draft. Some of them
have probably already been brought up in other threads.

1.3 Terminology

Is the definition of Upstream and Downstream server switched?

Should it be
Downstream
Diameter Proxy Servers identify a downstream server as one that
is providing routing service towards the node where the message
originated.

Upstream
Diameter Proxy Servers identify a upstream server as one that
is providing routing service away from the node where the
message originated.

2.0 Protocol Overview
The reference to Strong Security should be End-to-End Security

4.4 Grouped AVP Values
What about Paul's idea of being able to define optional AVPs
in a grouped AVP?

6.0 Capability Negotiation

How can you tell what extensions from a specific vendor you support.
As I understand it the Supported-Vendor-Id AVP only tells you the
IANA assigned number for that vendor, not what extensions from that
vendor that is supported. Perhaps there should be a grouped AVP
Supported-Vendor-Extensions which containing the
Vendor-Id AVP and a Vendor-Extension-Id AVP
that contains the Vendor specific Extension Id taken from that vendors
private Extension Id space.

8.0 Peer State Machine
I have not implemented the new state machine, but from the looks
of it it seems complicated. Why not use a simple backoff instead
of an election when a raise condition occurs. I.e. when the nodes
discover the raise condition, they both disconnect and tries again
after a short period of time. Sure it may take some extra time to
set up the connection, but the gain by having a simpler state machine
seems worth it. The backoff time does not have to be so long, RTT + some
random number of msec.

10.1.3 Offending-Command-Code AVP
should this realy be under MRI, an unknown command should result
in an DSI according to the table in section 10

11.1 Authorization Session State Machine

Open    Authorization-Lifetime expires   send serv.    Open
                                         specific
                                         auth req

How can a client send a server specific auth request? In the case of MIP
does it not need to receive a MIP Reg Req? If it has not received a req
from the Mip MN to update the tunnel  I believe it should send a STR. Thus
it should be

Open    Authorization-Lifetime expires   send STR      Discon

11.2 Accounting Session State Machine
is the following state missing?

Open   receive Interim Record       send Ack     Open

16.1 Base Protocol Command AVP Table
the Accounting Extension Id AVP is missing

I still don't like that a Vendor Specific AVP can't be mandatory. An
example. Say that I would like to distribute some configuration data to the
FA in an AMA and that I require it to understand the format. If it does not
understand the format I would like it to reject the session. How can I do
this without setting the Mandatory bit in the AVP?

And what about a company having a vendor specific extension. If the company
has two sites they can not comunicate with each other since the operator
that will proxy the message does not understand the extension. What I'm
trying to say is that a proxy should not care about the message unless it is
handled localy. Or can you advertise wildcard without supporting it locally?

/Fredrik

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 10 May 2001 08:52:26 -0700

> is providing routing service away from the node where the

yup, I cut and paste too hastily :(

> The reference to Strong Security should be End-to-End Security

yes, and there were a few other places too :(

> What about Paul's idea of being able to define optional AVPs

I am waiting for WG concensus. I think that the chairs need to step in
to help us out. I have two people that have asked for this, Erik has
opposed it. That's not exactly what I would call concensus, so Bernard
and Dave need to intervene, and help us out.

> private Extension Id space.

We agreed, and section 2.3/4 states, that Extension Ids are not vendor
specific. If a vendor needs an extension identifier, it is taken from the 
extension identifier namespace.

> seems worth it. The backoff time does not have to be so long, RTT + some

Because we need something that reliably works. Back-off will simply delay
the connection process, and the peers could select a random number that
is close enough to each other that the back-off process occurs again.

I've implemented it, and it really isn't that bad at all.

> in an DSI according to the table in section 10

Right. I am still waiting to get some concensus on the elimination of
the MRI proposal, and if we do, then the error handling sections will
be consolidated.

I prefer to wait until I know what's happening to the MRI before I make
more temporary changes :)

> from the Mip MN to update the tunnel  I believe it should send a STR. Thus

serv = service. Let me clear that up.
> Open    Authorization-Lifetime expires   send STR      Discon

This would be on the server side, and this action already
exists in the FSM.

> Open   receive Interim Record       send Ack     Open

yes it was missing.

> the Accounting Extension Id AVP is missing

right, and the entry was incorrect. It is now:
                               DRI
Acct-Extension-Id             |0+ |0  |0  |0  |0  |0  |0  |0  |
Auth-Extension-Id             |0+ |0  |0  |0  |0  |0  |0  |0  |

> this without setting the Mandatory bit in the AVP?

The IESG is very concerned about interoperability, or lack thereof, when
vendors start adding vendor-specific AVPs with the 'M' bit set. I will
let them defend their position.

> handled localy. Or can you advertise wildcard without supporting it locally?

Let's assume extention x is proprietary,  * is wildcard, and FOO is the
vendor specific command:

   A                  P                 B

   --- DRI ext=x --->  <--- DRI ext=x ---
   <-- DRI ext=* ---   --- DRI ext=* --->
   --- FOO ext=x --->  --- FOO ext=x --->

That would work just fine.

Thanks,

PatC

---

From: "Fredrik Johansson" <[email-masked]>
Date: Fri, 11 May 2001 08:29:15 +0200

>and Dave need to intervene, and help us out.

Ok, then it's 2-1, not much of a WG concensus, hope that more people speaks
up.

>extension identifier namespace.

Ok, that's fine with me as long as it's not to complicated to get an id
assinged.
What scares me is that new Ids are available for assignment via Standards
Action.
Doesn't it mean that it has to be standardized in the IETF, which can be
quite lengthy
process :-(

>I've implemented it, and it really isn't that bad at all.

Ok, I'll take your word for it and hope I come to the same conclusions.

>let them defend their position.

I don't understand why it makes the protocol not interoperable, what will
happen
is that the node that sends an avp with the mandatory bit set to a node that
does not understand it will get an error message back saying something like
"I did not understand your avp, please try again without it if you still
would
like to use this service"

>That would work just fine.

Ok, so it's ok for a node to advertise wildcard allthough it does not
support
all extensions locally. Then there is no problem.

thanks

/Fredrik

---

From: Erik Guttman <[email-masked]>
Date: Fri, 11 May 2001 09:57:09 +0200 (MET DST)

"Fredrik Johansson" <[email-masked]> wrote:
> Ok, then it's 2-1, not much of a WG concensus, hope that more people 
> speaks up.

We are not voting here.  draft-ietf-aaa-issues-04.txt akes the case for 
a regular grammar for Diameter.  This WG draft has gone through WG last 
call.  It's really up to Paul and Dave to show that this *WG consensus 
action* is off base.

The perception is that this is at the cost of some RADIUS-like
flexibility.  Well, Diameter allows arbitrary AVPs to be added 
to a message, just not to a Group value.  And RADIUS didn't have 
Group values. So the ability to add arbitrary AVPs to Groups doesn't 
amount to less flexibility for Diameter than was present in RADIUS.

The Grouped AVP replaces the complex data type and the Group-AVP bag. 
It facilitates (1) a data dictionary compatible with complex data 
(2) ensures that all components of complex data are present 
(3) eliminates the need for specialized parsing code for complex data 
(4) facilitates automatic parsing / message completeness checking.

If Group values can include arbitrary AVPs, I do not see that they
serve these 4 ends.  

If the constraints on Group values are truly thought to be too 
binding, let's just eliminate the Group type altogether and go 
back to the RADIUS model of 'strictly' non-organized AVPs 
bundled together to form a message.  But let's hear some good
arguments why this is preferable before revising the position 
supported by draft-ietf-aaa-issues-04.txt.

Erik

---

From: David Frascone <[email-masked]>
Date: Fri, 11 May 2001 10:01:02 -0500

Ok, I know I opened this can of worms . . 

> call.  It's really up to Paul and Dave to show that this *WG consensus 

The issues draft stated that perhaps complex AVPs should be replaced
with a strictly defined grouped AVP.  The way I read the document was that
the issues need to be solved, and that we are here to solve them.

In my opinion, that issue is phrased incorrectly, and I think the complex
AVPs needed to be replaced with grouped AVPs, but not strictly defined.
This (IMO, as always) makes the protocol simpler, and also adds functionality
by allowing the flexibility in a complex type that Diameter has in a message.

If, on the otherhand, we adhere to a strict BNF, then we gain NO advantage
over a complex type, except that it grows in size.

> (2) ensures that all components of complex data are present 

But, this seems like an application issue, not a transport one.  (Assuming
that the transport would be making these checks)

> (3) eliminates the need for specialized parsing code for complex data 

The specialized parsing code has already been written to parse normal
AVPs themselves.

> If Group values can include arbitrary AVPs, I do not see that they

I agree.  But, I don't think the parser/transport whould be doing 
completeness checking.  

And, I feel that if it is this strict, why are we having the overhead of
the AVPs at all?  Why not keep it complex.  It's even easier to parse, just
point a structure at it.

> supported by draft-ietf-aaa-issues-04.txt.

I didn't read a "position" in the draft, just a question.  And, I think
the question might have been stated improperly.

As for arguments, I don't see why we should use the overhead of Grouping
our AVPs, if we don't reap all of the benefits.

In my opinion, these are the benefits to loosly defined (if at all) grouped
AVPs:

	o)	It can be parsed by anyone.  (It's not a blob)
	o)	It is extensable.  If a server wants to add another avp
		to some grouped information, it can.

Reasons why Grouped AVPs with a strict definition is better:
	o)	It can be parsed by anyone.  (It's not a blob)
	o)	The syntax can be checked at the transport level.

Reasons why complex data is better
	o)	It is the smallest (transport wise)

So, I think we are trading transport layer completeness checking with 
extensibility.

I'd rather have extensibility.

-Dave

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 11 May 2001 08:55:04 -0700

> Doesn't it mean that it has to be standardized in the IETF, which can be

Correct, as requested by the IESG. However, I believe that now that the
protocol has a much better way to allowing intermediate proxies to handle
extensions it doesn't recognize (by setting the 'A' bit, instead of
having to know what the correct command code is), this may no longer be
an issue.

Bernard/Dave, is this true?

> Ok, I'll take your word for it and hope I come to the same conclusions.

Well, I had originally implemented a state machine that was exchanged as
private e-mail, and was radically different from what is in -03. It took
me one day to modify my code to support the new state machine, and with
the exception of the function that does the look up, based on event/state
that required changes, the rest was a re-write.

It took me about a day to implement/test.

> like to use this service"

They are worried about vendors abusing the protocol, as many have done with
other protocols, and ending up with non-interoperable solutions. If you feel
the need to create a vendor-specific solution, then create your own 
extension.

> all extensions locally. Then there is no problem.

correct.

PatC

---

From: Paul Funk <[email-masked]>
Date: Fri, 11 May 2001 13:22:17 -0400

The issue of flexibility in the ABNF for a grouped AVP is clearly one that 
Dave Frascone and I feel strongly about, and Erik Guttman has ardently 
spoken against.

The way the draft is written now, if you wanted to define a grouped AVP, 
you'd have to specify the exact sequence of AVPs it must contain. If you 
realize later than additional information would useful, you'd have to define 
a brand new grouped AVP. If you want to collect a set of attributes in a 
group but allow some to be present and some not, you'd have to define a 
separate grouped AVP for each possible combination.

One argument against polymorphic groups is that we have no concrete 
examples of a hard requirement for it. Well, it we wait for the dispositive 
example to come along, we may be out of luck when it does.

Meanwhile, there are many reasons to anticipate polymorphic groups will 
become necessary in the future.

How will we be able to return complex policy or hierarchical accounting 
data without flexibility in grouping?

People have been told to use XML inside a Diameter AVP or just package 
some other accounting format within a Diameter AVP, because Diameter 
as a protocol is too "flat" to handle their data. But if we allow polymorphic 
groups, we'd be able to render the XML data model perfectly when that 
becomes necessary.

Plus, my original email on the subject raised an issue which no one has 
yet attempted to address: 

The draft states that when a Redirect DSI is issued, it provides the 
addresses/ports of one or more home servers to redirect to in the 
Redirect-Host grouped AVP, and it may also provide certificates 
for the home server. The question is, if different home servers have 
different certificates, how do you associate each home server with 
the appropriate certificate without extending the Redirect-Host AVP. 
Pat, any thoughts on this question?

Erik, I responded to your points in line.

Paul

>call.  It's really up to Paul and Dave to show that this *WG consensus 

We can argue about the rules of the game, or we can argue about the 
issues. 

And, since Fred revived the question, I'm wondering whether it isn't 3-1 by 
now. Is this the beginnings of a groundswell?

>amount to less flexibility for Diameter than was present in RADIUS.

The only grouping concept in RADIUS is tagged tunnel attributes. But 
in RADIUS, you can have a subset of the tunnel attributes in a tag 
group, not necessarily all of them. And, if new tunnel attributes are 
defined, they can be added to the tag group. So that hack of a 
mechanism in RADIUS provides more flexibility than what we have 
defined for Diameter.

>If Group values can include arbitrary AVPs, I do not see that they

First, let's be precise. I never proposed that grouped AVPs can include 
arbitrary AVPs. I proposed that grouped AVPs be defined via ABNF, just 
as the Diameter message itself is. The ABNF can be as flexible or 
restrictive as is deemed necessary. I would hope that people would 
define new AVPs flexibly. But they could still have rules for required 
attributes, sequencing, etc.

I think that an ABNF-specified group absolutely does meet the four 
goals listed above.

>supported by draft-ietf-aaa-issues-04.txt.

Obviously, no one is saying we should eliminate grouped AVPs 
entirely.

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 11 May 2001 10:44:27 -0700

On Fri, May 11, 2001 at 01:22:17PM -0400, Paul Funk wrote:

[staying away from this one as much as I can, but have the following comment]
> Pat, any thoughts on this question?

Certificates are distributed as specified in the end-to-end security
draft. A certificate includes the owner's identity. Therefore, there
is no need to combine the certs in the Grouped-AVP because matching
the server with the cert occurs by looking at the details of the cert.

PatC

---

From: Erik Guttman <[email-masked]>
Date: Fri, 11 May 2001 21:17:26 +0200

Davem

> over a complex type, except that it grows in size.

The advantages are that a strict, standard BNF can be expressed in
formal
notation which is easily interpreted without knowing anything more.  

draft-ietf-issues-04.txt, section 
9.3 Formal notation for application specific data types

   The use of a formal notation for the definition of (potentially
   complex) application specific data types has proven to be valuable,
   especially if a protocol is designed the be extensible. A formal
   notation enables tools that can (a) verify the correctness of data
   definitions, (b) automate some of the implementation process, (c)
   help in debugging scenarios, and (d) enable implementations that can
   be easily adapted to vendor specific extensions. Furthermore, the
   separation of the data definitions from the core protocol
   specification allows extension writers to re-use existing data
   definitions (e.g. for addressing types) and it thus promotes
   consistency across a variety of management protocols.

   The formal notation will serve the extensibility of AAA
   implementations in terms of their data storage, interpretation,
   validation, display, etc.  Support for the formal notation is in this
   sense an implementation option to enhance support ease the
   integration of extensions, but not required for compliance.

If data types are not specified by strict rules, like what is there
and what the order is, there is no way to satisfy (a)-(d) in a 
straightforward way.  Just saying there may be an ABNF written for
any arbitrary message doesn't mean that existing software will have
access to it.  

Note that the ABNF rules and grammar I wrote, which is used in the 
Diameter spec is helpful for elucidating the protocol, but it is *not* 
standard ABNF.  It is probably extremely difficult for a machine to 
process the special rules, like for the AVPs surrounded by '[' ']'.

> that the transport would be making these checks)

I agree.  Also from section 9.3 of draft-ietf-aaa-issues-04.txt:

   The formal notation is not intended to define the transfer encoding
   (the on-the-wire byte formatting). The DIAMETER specifications of the
   base types include these definitions and rules.

> The specialized parsing code has already been written to parse normal

You are missing the point.  Regular grammar plus atomic data types 
eliminate the need for specialized parsers to be used on arbitrary
new commands and AVPs.  Generic code could be used for (a) checking
AVP records in memory or storage, (b) display and analysis for
sniffers, (c) diameter servers which do not need to interpret a 
particular AVP, but will otherwise process them, etc.  Also, although
this is not the primary intent, it would be possible to write code
to encode and decode arbitrary AVPs from the wire on the basis of
a data dictionary - provided that the data dictionary rules were
simple and regular enough.
	
> I agree.  But, I don't think the parser/transport whould be doing

It would be easy to generate a parser purely from the definition of
the AVP, provided all data types were regular (atomic or composed
of atomic components in a fixed manner).

> the AVPs at all?  Why not keep it complex.  It's even easier to parse, just

This requires specialized software, as it cannot be expressed as a 
regular composition of atomic data types.  (If we follow your 
argument to its conclusion, why have AVPs at all?  We can just 
define a new protocol for each attribute.)

> the question might have been stated improperly.

The position is in draft-ietf-aaa-issues-04.txt, Section 9.3.1.

   The goals for developing a formal notation would be to facilitate the
   implementation of various functions, such as a data dictionary, a
   packet filter or an extensible administrative console.  Such
   facilities have been shown to be useful in RADIUS implementations.

   The facilities based on formal notation for supported AVP would:

      - make it possible to add new AVP storage, type checking, etc.
        support without changing code.
      - make it easier to extend functionality to sniffers, debuggers
        management tools and DIAMETER implementations (potentially
        without adding code).

   Non-goals are to define a formal notation which can express any
   possible (i.e., non-DIAMETER) message.  We only need to express
   DIAMETER messages which have been currently defined and those
   messages which are likely to be defined, given experience with
   RADIUS. It is thought that support for extensible functions would be
   a useful but not mandatory feature for DIAMETER implementations.

>         o)      The syntax can be checked at the transport level.

And at the spec level, and at the code level, and at the storage level,
and...

>         o)      It is the smallest (transport wise)

Diameter is already quite verbose.  The maximum that is added is the
8 (possibly 12) byte header.  For an Unsigned32 this is a considerable 
overhead in percentage terms, but overall, considering the number of
AVPs present in a message, the savings of Complex over Group is nominal.
I checked out the difference in the Diameter commands (at that time) and
found the difference - all AVPs considered - to be less than 10% in all
cases.

> So, I think we are trading transport layer completeness checking with

We are trading formality for extensibility.

draft-ietf-aaa-issues-04.txt, 9.4  Ordering of Data

   The current DIAMETER specification says that AVPs can be added
   arbitrarily as long as the required AVPs are included and AVPs which
   introduce special requirements and even dependencies between AVPs.
   (The Session-Id AVPs SHOULD appear first, Integrity-Check-Value AVPs
   must follow the data to be protected, the Nonce AVP must appear
   before an Integrity-Check-Value AVP, the last Nonce AVP before an
   Encrypted-Payload AVP is significant for MD5 payload hiding and so
   on.)

   It seems useful to formally define the ordering constraints,
   potentially restricting the "AVPs can be added arbitrarily" rule to
   simplify the validation of messages. Note that it is necessary to
   provide for optional AVPs within a message so that the optional AVPs
   can be protected by an Integrity-Check-Value AVP.

> I'd rather have extensibility.

Please address how - without the current grammar for Grouped AVPs - 
and with *only one* published grammar for each AVP - we can achieve 
the objectives we set out to achieve in the issues draft.  (And if 
you disagree with the 'issues' draft - please clarify how).

Erik

._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
E r i k   G u t t m a n         SHORT msgs: [email-masked]
Sr Staff Engineer, Sun Microsystems       Email: [email-masked]
Altrotstrasse 31, D-69190 Walldorf Germany   Mobile: +49 172 865 5497

---

From: Paul Funk <[email-masked]>
Date: Fri, 11 May 2001 15:39:41 -0400

>the server with the cert occurs by looking at the details of the cert.

I presume the cert would include the name of the server, but not its IP 
address. But Redirect-Host contains IP address. So I still don't get it.

Paul

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

---

From: Pat Calhoun <[email-masked]>
Date: Fri, 11 May 2001 12:52:24 -0700

> address. But Redirect-Host contains IP address. So I still don't get it.
The obvious fix is for the Redirect-Host AVP to contain an FQDN instead,
which can be resolved via DNS anyways.

Would this fix the problem?

PatC

---

From: Paul Funk <[email-masked]>
Date: Fri, 11 May 2001 20:16:09 -0400

>Would this fix the problem?

Oh well, I guess I can't goad you into taking a position on polymorphic 
groups.

Sure, it fixes the problem, at least as we currently understand the problem. 
To do so, you needed to overload a single AVP with information that both 
dereferences an entity's address and its certificate. As long as the same 
FQDN can stand for both, yes, it will work.

But this illustrates the problem with fixed groups -- you need to anticipate 
everything in advance, because you'll have no room to improvise later. If this 
problem was noticed a month later, we'd have to invent a alternative AVP to 
package up the same information in a different form, because Redirect-Host 
would be untouchable.

Plus, we're committing to FQDN as the subjectAltName in a cert, and E2E 
has not even been well discussed yet. What if we want to be able to have a 
single cert for an entire realm, so you can sign things without knowing
exactly 
which server it will go to? 

Paul

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]