From owner-aaa-bof@merit.edu  Tue Jan  9 20:10:03 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23950
	for <aaa-archive@odin.ietf.org>; Tue, 9 Jan 2001 20:10:03 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id BC9E35DF84; Tue,  9 Jan 2001 19:49:25 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id CB2CE5DF85; Tue,  9 Jan 2001 19:31:12 -0500 (EST)
Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110])
	by segue.merit.edu (Postfix) with ESMTP id 03E225DEF2
	for <aaa-wg@merit.edu>; Tue,  9 Jan 2001 19:17:00 -0500 (EST)
Received: from Interlinknetworks.com (unknown [198.108.5.3])
	by aaa.interlinknetworks.com (Postfix) with ESMTP
	id 0496474; Tue,  9 Jan 2001 19:17:06 -0500 (EST)
Message-ID: <3A5BAA1A.50A452C3@Interlinknetworks.com>
Date: Tue, 09 Jan 2001 19:17:30 -0500
From: David Spence <DSpence@Interlinknetworks.com>
Organization: Interlink Networks, Inc.
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>
Cc: Erik.Guttman@germany.sun.com, aaa-wg@merit.edu
Subject: Re: Choice of Data Model SMI vs XML vs. UML
References: <Roam.SIMC.2.0.6.978716737.12687.erikg@sun-ffm.germany> <200101091323.OAA20320@henkell.ibr.cs.tu-bs.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Juergen Schoenwaelder wrote:
>... 
> >> David's proposal comes yet again from another different angle. Its
> >> main background is the observation that AVP combinations that can
> >> be meaningfully combined in a message are actually not well
> >> defined.
> 
> Erik> I do not know that this is a very big issue.  If DIAMETER
> Erik> command codes specify what MUST be there and how to interpret
> Erik> it, other AVPs which are present should not prevent proper
> Erik> interpretation of the command.
> 
> Erik> We have been around this point a number of times - there are
> Erik> good reasons to use the RADIUS approach as it is flexible:
> Erik> Specify what is required, allow arbitrary ordering and
> Erik> additional AVP message components.  No one has argued for
> Erik> removing this flexibility, though there has been discussion
> Erik> about how this would facilitate a formal ABNF for the protocol.
> 
> There are again two issues here. The first one is a protocol issue,
> namely whether it is legal so ship additional AVPs with a message.
> The second one is the question which set of AVPs actually consitute a
> given message. Even the current specs use a kind of a BNF notation
> trying to make that clear. But there are issues because the specs do
> not really say what the semantics of the BNF notation are.
>...

It's actually worse than that.  The presence of the BNF gives one the
impression that the permissible contents of each message are specified.  But
the BNF is not complete.  The BNF for both the AA-Request and AA-Answer
messages in draft-calhoun-diameter-nasreq-05.txt contain the line:

   [<Authorization AVPs>]

But the term <Authorization AVPs> is not expanded.  The implication might be
that any of the AVPs defined in section 6 would do.  Section 6, however, is
divided into subsections.  Some of the subsections, such as section 6.2,
"Framed Access Authorization AVPs", and section 6.3, "Non-Framed Access
Authorization AVPs", can be inferred to be mutually exclusive, i.e., you
would not expect to find an attribute defined in 6.2 and an attribute
defined in 6.3 to appear in the same message.  But the draft does not state
that explicitly.  Even if the draft were to state that explicitly, one might
then assume that any of the attributes from section 6.2 could be
meaningfully combined when providing a framed access service.  What, then,
would it mean if the Framed-IPX-Network and Framed-AppleTalk-Network AVPs
were included in the same message?  My problem with the BNF is that it
appears to specify permissible messages but does not.  RADIUS, at least,
does not make that pretension.

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



From owner-aaa-bof@merit.edu  Tue Jan  9 20:25:00 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24146
	for <aaa-archive@odin.ietf.org>; Tue, 9 Jan 2001 20:25:00 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id BDB6B5DFBF; Tue,  9 Jan 2001 20:16:16 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id D18C65E0E5; Tue,  9 Jan 2001 20:03:07 -0500 (EST)
Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110])
	by segue.merit.edu (Postfix) with ESMTP id F41855E16D
	for <aaa-wg@merit.edu>; Tue,  9 Jan 2001 19:48:44 -0500 (EST)
Received: from Interlinknetworks.com (unknown [198.108.5.3])
	by aaa.interlinknetworks.com (Postfix) with ESMTP
	id 0C3D574; Tue,  9 Jan 2001 19:48:52 -0500 (EST)
Message-ID: <3A5BB18A.F2877B39@Interlinknetworks.com>
Date: Tue, 09 Jan 2001 19:49:14 -0500
From: David Spence <DSpence@Interlinknetworks.com>
Organization: Interlink Networks, Inc.
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Erik Guttman <Erik.Guttman@germany.sun.com>
Cc: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>, Pat.Calhoun@eng.sun.com,
        aaa-wg@merit.edu
Subject: Re: Choice of Data Model SMI vs XML vs. UML
References: <Roam.SIMC.2.0.6.979062278.19067.erikg@sun-ffm.germany>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Erik Guttman wrote:
>... 
> Why can't we standarize DIAMETER (its current informal spec) and later
> model it with SMIng?  If we find errors in the spec, we can cycle
> it in the standards process.  I think this would be a useful endeavor.
> Once SMIng notation is standardized, we could begin this process of
> rewriting the DIAMETER specification with the goal of improving it.
>...

Question:  What if the SMIng model were more restrictive than the original
DIAMETER standard?  In other words, what if the SMIng model prohibited
message contents that the pre-SMIng DIAMETER standard allowed (but were
either nonsensical or at least ambiguous) -- like including the
Framed-IPX-Network and Framed-AppleTalk-Network AVPs in the same message? 
It would be good to avoid having to make incompatible changes like that.

Would it make any sense to standardize part of DIAMETER now, like the base
protocol and Mobile IP extensions, without data modeling, but delay
standardizing the NASREQ extensions until the NASREQ data elements can be
modeled?  I'm thinking that with NASREQ, we have less time pressure (because
of the existence of RADIUS), and so the successor to RADIUS should provide
the best platform for future expansion that we can.  It may be argued that
the NASREQ application is simple enough that data modeling is unnecessary,
but I fear that won't always be the case.  You ought to be able to encompass
more services in the future, such as DSL, broadband, and LAN access. 
Without data modeling, things are going to get really messy.

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



From owner-aaa-bof@merit.edu  Tue Jan  9 22:43:17 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26917
	for <aaa-archive@odin.ietf.org>; Tue, 9 Jan 2001 22:43:17 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id DDEA85DD91; Tue,  9 Jan 2001 22:43:01 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id C45345DE11; Tue,  9 Jan 2001 22:43:01 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id B10ED5DD91
	for <aaa-wg@merit.edu>; Tue,  9 Jan 2001 22:43:00 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA24911;
	Tue, 9 Jan 2001 19:42:56 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA12992;
	Tue, 9 Jan 2001 19:42:56 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id SAA09224;
	Tue, 9 Jan 2001 18:53:57 -0800 (PST)
Date: Tue, 9 Jan 2001 18:50:21 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: Re: Choice of Data Model SMI vs XML vs. UML
To: David Spence <DSpence@Interlinknetworks.com>
Cc: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>,
        Erik.Guttman@germany.sun.com, aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <3A5BAA1A.50A452C3@Interlinknetworks.com>
Message-ID: <Roam.SIMC.2.0.6.979095021.7143.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> What, then,
> would it mean if the Framed-IPX-Network and Framed-AppleTalk-Network AVPs
> were included in the same message?  My problem with the BNF is that it
> appears to specify permissible messages but does not.  RADIUS, at least,
> does not make that pretension.

I actually do not see why one cannot run both IPX and Appletalk over the same
PPP connection. Am I missing something fundamental?

In any case, I do agree (and I don't think that anyone has argued this) that
the BNF needs to change. However, how drastic must the change be? This is a
real question, because if one was to attempt to define all possible
combinations, the RFC would be ungodly long (perhaps as an appendix it would
be ok).

PatC




From owner-aaa-bof@merit.edu  Tue Jan  9 23:30:09 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27228
	for <aaa-archive@odin.ietf.org>; Tue, 9 Jan 2001 23:30:09 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 50ADE5DE48; Tue,  9 Jan 2001 23:29:36 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id DF6D15DF81; Tue,  9 Jan 2001 23:28:35 -0500 (EST)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id C339C5E1B4
	for <aaa-wg@merit.edu>; Tue,  9 Jan 2001 23:27:46 -0500 (EST)
Received: from gwzpc ([10.64.194.1] (may be forged)) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id UAA21758; Tue, 9 Jan 2001 20:26:58 -0800 (PST)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "David Spence" <DSpence@Interlinknetworks.com>,
        "Erik Guttman" <Erik.Guttman@germany.sun.com>
Cc: "Juergen Schoenwaelder" <schoenw@ibr.cs.tu-bs.de>,
        <Pat.Calhoun@eng.sun.com>, <aaa-wg@merit.edu>
Subject: RE: Choice of Data Model SMI vs XML vs. UML
Date: Tue, 9 Jan 2001 20:17:06 -0800
Message-ID: <NDBBIHMPILAAGDHPCIOPCECDDBAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <3A5BB18A.F2877B39@Interlinknetworks.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

David Spence [mailto:DSpence@Interlinknetworks.com] writes:

> Erik Guttman wrote:
> >...
> > Why can't we standarize DIAMETER (its current informal spec) and later
> > model it with SMIng?  If we find errors in the spec, we can cycle
> > it in the standards process.  I think this would be a useful endeavor.
> > Once SMIng notation is standardized, we could begin this process of
> > rewriting the DIAMETER specification with the goal of improving it.
> >...
>
> Question:  What if the SMIng model were more restrictive than the original
> DIAMETER standard?  In other words, what if the SMIng model prohibited
> message contents that the pre-SMIng DIAMETER standard allowed (but were
> either nonsensical or at least ambiguous) -- like including the
> Framed-IPX-Network and Framed-AppleTalk-Network AVPs in the same message?

In this case, the model would be broken. AFAIK, it is neither nonsensical
nor ambiguous to include both the Framed-IPX-Network and
Framed-AppleTalk-Network AVPs in the same message, since PPP can carry both
(and IP, too!) simultaneously.

> It would be good to avoid having to make incompatible changes like that.

Since the history of SNMP is one of incompatible changes, I fail to see why
anything should change now ;-)

>
> Would it make any sense to standardize part of DIAMETER now, like the base
> protocol and Mobile IP extensions, without data modeling, but delay
> standardizing the NASREQ extensions until the NASREQ data elements can be
> modeled?  I'm thinking that with NASREQ, we have less time
> pressure (because
> of the existence of RADIUS),

The reason for the inception of this effort (some 4 years ago) was the
inadequacy of RADIUS.  I can't see how the situation has improved.

> and so the successor to RADIUS should provide
> the best platform for future expansion that we can.  It may be argued that
> the NASREQ application is simple enough that data modeling is unnecessary,
> but I fear that won't always be the case.  You ought to be able
> to encompass
> more services in the future, such as DSL, broadband, and LAN access.

In the future?  RADIUS (or bizarre, usually proprietary, variants thereof)
is being used for these things (and more) right now.

> Without data modeling, things are going to get really messy.

They already have, some time ago.  We _do not_ need to spend another three
years blathering about silver bullets.

>
> --
> David Spence                            email:
> DSpence@Interlinknetworks.com
> Interlink Networks, Inc.                phone: (734) 821-1203
> 775 Technology Drive, Suite 200         fax:   (734) 821-1235
> Ann Arbor, MI 48108
> U.S.A.
>
>




From owner-aaa-bof@merit.edu  Wed Jan 10 08:03:54 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15157
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 08:03:54 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 109DC5DDAC; Wed, 10 Jan 2001 08:00:21 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id F01A25DDE8; Wed, 10 Jan 2001 08:00:20 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 43FBB5DDA6
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 08:00:19 -0500 (EST)
Received: from efra05-home.Germany.Sun.COM ([129.157.43.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA04672;
	Wed, 10 Jan 2001 05:00:07 -0800 (PST)
Received: from stag (d-ehdb03-142-95 [129.157.142.95])
	by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id OAA23535;
	Wed, 10 Jan 2001 14:00:04 +0100 (MET)
Message-ID: <00e201c07b04$8d162be0$5f8e9d81@stag.Germany.Sun.COM>
From: "Erik Guttman" <erik.guttman@sun.com>
To: <aaa-wg@merit.edu>, "Randy Bush" <randy@psg.com>
Cc: "Erik Guttman" <erik.guttman@sun.com>
Subject: diameter grammar proposal
Date: Wed, 10 Jan 2001 13:55:02 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit



Folks,

I propose the following section be added to the DIAMETER base spec.
This will allow us to specify DIAMETER in a more formal way.  This is
unfortunately not as formal as a BNF would be, but DIAMETER messages
allow for arbitrary ordering of many elements.   Still, we need to
be able to specify that some elements may appear only once, and some
have to appear in fixed positions.  I believe this grammar suffices
to do this.  Please send comments.

(Randy, does this hold water?)

Erik
---------------------------------------------------------------------

1.3 Notation

   The DIAMETER protocol is composed of messages which have three
   components - a message header, a command code and a set of AVPs.
   Each message type is distinguished by a single command code.
   Command are specified using the following notation.

     Command-Code-Name ::= <DIAMETER-Header: #>
                          { qual AVP }
                          qual [ qual AVP ]
                          qual < AVP >

   The symbol # will be replaced by the command Id which is to be
   placed in the message header.  The symbol AVP MAY be replaced
   by the names of any specific AVP.  
 
   Elements surrounded by less than, greater than '<' and '>' are
   FIXED in sequence.   For example, the DIAMETER header MUST
   precede all AVPs.

   Elements surrounded by set brackets '{' and '}' are REQUIRED
   to be present in the message.  They MAY be in any order within
   the message provided they do not violate order imposed by message
   fixed elements in the grammar (which are defined between '<' 
   and '>' brackets.)

   Elements surrounded by square brackets '[' and ']' are OPTIONAL.
   AVPs which are listed in this section MAY be included in the
   message, in any order, provided they do not violate order imposed
   by fixed message elements in the grammar.  AVPs listed in FIXED
   or REQUIRED sections MUST NOT be considered OPTIONAL as well.  
   An AVP required to appear once in one section MUST NOT, therefor,
   be included as the result of an 'OPTIONAL AVP' rule.

   The token 'qual' can be the following:
     
     omitted    One instance of the following entry is required.
      '*'       Zero or more instances of the following entry are 
                required.
      '+'       One or more of instances of the following entry
                are required.
      '?'       Zero or one of instances of the following entry
                are required.
 
     Example-Command ::= <DIAMETER-Header: 9999999>
                        { User-Name *Host-Name }
                        * [ AVP ]
                        ? < Integrity-Check-Vector >

   The command defined by the preceding grammar MUST begin with a
   DIAMETER header, with the command code Id set to 9999999.  There
   follows a User-Name AVP, zero or more Host-Name AVPs and zero or
   more arbitrary other AVPs (but not User-Name, Host-Name or 
   Integrity-Check-Vector AVPs).  The REQUIRED and OPTIONAL AVPs
   can be permuted into any order, provided that none of them come 
   before the Header. 

   DIAMETER messages which violate the grammar defined for the
   command code are considered malformed and are rejected.  See
   Section 5.0.







From owner-aaa-bof@merit.edu  Wed Jan 10 08:16:46 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15661
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 08:16:45 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 6B4395DDA6; Wed, 10 Jan 2001 08:15:11 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 2BA635DDD0; Wed, 10 Jan 2001 08:15:11 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id D75765DDA6
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 08:15:08 -0500 (EST)
Received: from efra05-home.Germany.Sun.COM ([129.157.43.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA14407;
	Wed, 10 Jan 2001 05:15:06 -0800 (PST)
Received: from stag (d-ehdb03-142-95 [129.157.142.95])
	by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id OAA22127;
	Wed, 10 Jan 2001 14:15:04 +0100 (MET)
Message-ID: <011d01c07b06$a545a900$5f8e9d81@stag.Germany.Sun.COM>
From: "Erik Guttman" <erik.guttman@sun.com>
To: <aaa-wg@merit.edu>, <diameter@diameter.org>
Subject: proposed new section for DIAMETER base specification
Date: Wed, 10 Jan 2001 14:10:03 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I am in the process of reworking the diameter specification
according to proposals made in the AAA design team.

I would like more feedback from implementors and working
group participants about some of these changes, as they
have received very little feedback.  I believe we do not want
to add requirements or change the protocol at this point unless
there is strong support and a good reason for doing so.

Please refer to draft-ietf-aaa-issues-04.txt, section 9.1
and draft-ietf-aaa-solutions-01.txt, section 9.1.

The proposed changed text would define 3 flags for the
diameter message header.  

-----------------------------------------------------------

Proposed change to section 2.1

   Flags
      The Message Flags field is five bits, and is currently unused.
      This field MUST be initialized to zero.

is replaced by ->

      The Message Flags field is five bits.  The following bits are
      assigned:

      +---+---+---+---+---+
      | z | z | E | I | R |
      +---+---+---+---+---+

      0x10 MUST be zero - this flag bit is reserved for future use.
      0x08 MUST be zero - this flag bit is reserved for future use.
      0x04 ('E' Expect Reply) The message solicits a response.
      0x02 ('I' Interrogation) The message is a Query or a Reply.
      0x01 ('R' Response) The message is a response another message.

      These flags are set depending on the command code used in a
      DIAMETER message.  This enables the type of message to be 
      interpreted, even if the specific command code is not recognized.
          
      Command Type   Flags Set
       Indication      - - -
       Request         E - -
       Answer          E - R
       Query           E I -
       Reply           E I R

      A DIAMETER node MUST NOT set these flags in any other combination.
      A DIAMETER node receiving a message in which these flags are not
      set appropriately SHOULD NOT reject the message for this reason,
      but MAY log the event for diagnosis.





From owner-aaa-bof@merit.edu  Wed Jan 10 09:24:21 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17579
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 09:24:21 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 6922D5DDEA; Wed, 10 Jan 2001 09:24:06 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 57D265DDE8; Wed, 10 Jan 2001 09:24:06 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 46A785DDC4
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 09:24:05 -0500 (EST)
Received: from efra05-home.Germany.Sun.COM ([129.157.43.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA25508;
	Wed, 10 Jan 2001 06:24:01 -0800 (PST)
Received: from stag (d-ehdb03-142-95 [129.157.142.95])
	by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id PAA11339;
	Wed, 10 Jan 2001 15:23:54 +0100 (MET)
Message-ID: <012b01c07b10$4314be60$5f8e9d81@stag.Germany.Sun.COM>
From: "Erik Guttman" <erik.guttman@sun.com>
To: <diameter@diameter.org>, <aaa-wg@merit.edu>
Subject: data type modifications to DIAMETER
Date: Wed, 10 Jan 2001 15:18:52 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


As proposed in draft-ietf-aaa-issues-04.txt and 
draft-ietf-aaa-solutions-01.txt section 9.2, I am 
revising the basic data types in DIAMETER.

I do not list all the changes in this document - 
but the implications are the following.

 1. Data type changes:

    Old type        New type
    ------------    -------------
    Address         Address
    Data            OctetString
    String          OctetString
    Time            Unsigned32
    Integer32       Integer32
    Integer64       Integer64
    Complex         Grouped
                    Unsigned32
                    Unsigned64
                    Float32 
                    Float64
                    Float128

 2. Scalar quantities (Ids and so on from AVPs) had Integer32 type. 
    Now they have Unsigned32 type.

 3. String is now one interpretation of an OctetString.

 4. Time is now one interpretation of an Unsigned32 value.

 5. The biggest change is the elimination of the 'Complex' data 
    type.  Now all AVPs have an 'atomic' data type except for
    Grouped.  Grouped takes as its value a list of AVPs which
    have to be included (AVP header and all) in exactly the
    sequence specified.

Implications for DIAMETER implementations:

  The only real change is that Complex data types have been 
  restructured.  Code handling AVPs which were previously of
  type Complex will have to change.

  Code which handled the previous types will be easily mapped
  into the new data types (Integer32 -> Unsigned32, Time ->
  Unsigned32, String -> OctetString)  There are some subtle
  range checking changes to be made (maybe) since scalars are now
  Unsigned32 where before they were Integer32.
  
Rationale:

  See draft-ietf-aaa-issues-04.txt.  In short, there were several
  problems with the basic types used by DIAMETER.  (1) Some were
  interpretations (String and Time) not basic scalars.  (2) Some
  were ambiguous (Integer32 used as an unsigned scalar).  (3) Not
  including basic types (floats, mostly) makes future expansion
  hard.  (4) The types specified were incompatible with SMI and 
  SPPI data types. (5) The complex data type made it hard to
  create a general data model, easily automated parsers and
  general 'sniffers.'  All AVPs should either have atomic values
  or a list of AVPs as their values.  (6) The Grouped-AVP was
  unnecessarily complex. (7) Complex data types required a 'hack'
  for fixing the length of certain data fields (such as using 16
  bytes for addresses where they could be 4 bytes long).  This is
  no longer necessary.

Erik





From owner-aaa-bof@merit.edu  Wed Jan 10 09:50:34 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18288
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 09:50:34 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 940985DDC4; Wed, 10 Jan 2001 09:49:12 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 7F5FB5DE19; Wed, 10 Jan 2001 09:49:12 -0500 (EST)
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by segue.merit.edu (Postfix) with SMTP id 2E5FC5DDC4
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 09:49:11 -0500 (EST)
Received: (qmail 24525 invoked by uid 500); 10 Jan 2001 14:50:23 -0000
Date: Wed, 10 Jan 2001 08:50:23 -0600
From: David Frascone <dave@frascone.com>
To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Cc: aaa-wg@merit.edu
Subject: Re: DISCUSSION REQUESTED: ADIF, Batching, M bit
Message-ID: <20010110085023.H23197@newman.frascone.com>
Mail-Followup-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>, aaa-wg@merit.edu
References: <002101c078f3$54d67220$8a1b6e0a@arenanet.fi> <Roam.SIMC.2.0.6.979056867.8220.pcalhoun@nasnfs>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Roam.SIMC.2.0.6.979056867.8220.pcalhoun@nasnfs>; from Pat.Calhoun@Eng.Sun.COM on Tue, Jan 09, 2001 at 08:14:27AM -0800
X-encrypt-payload: no
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> 
> However, I think that specifying a recommended XML or SMI format for the
> accounting file that is written on the server MAY be a desirable goal.
> 

Good idea!  That way, the transport model is still clean, and we can also
specify an XML model for the accounting records.  I think this is the best
of both worlds.

-Dave



From owner-aaa-bof@merit.edu  Wed Jan 10 10:33:55 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19356
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 10:33:55 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 8BFA85DDF3; Wed, 10 Jan 2001 10:30:26 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 76EE05DDF6; Wed, 10 Jan 2001 10:30:26 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 1BB605DDF3
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 10:30:24 -0500 (EST)
Received: from efra05-home.Germany.Sun.COM ([129.157.43.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28054;
	Wed, 10 Jan 2001 07:30:22 -0800 (PST)
Received: from stag (d-ehdb03-142-95 [129.157.142.95])
	by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id QAA19223;
	Wed, 10 Jan 2001 16:30:20 +0100 (MET)
Message-ID: <015d01c07b19$8aa8efe0$5f8e9d81@stag.Germany.Sun.COM>
From: "Erik Guttman" <erik.guttman@sun.com>
To: "David Frascone" <dave@frascone.com>, <aaa-wg@merit.edu>
Cc: "Erik Guttman" <erik.guttman@sun.com>
Subject: Fw: diameter grammar proposal
Date: Wed, 10 Jan 2001 16:25:17 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dave,

>My problem is:  If you list all of the "optional" AVPs, then it seems like
>if an AVP is received that is not on the "optional" list, it is an error.
I
>think listing optional AVPs is problematic.


My solution to this problem is to allow the token 'AVP' to stand for
*any* AVP.   In the example:

>>      Example-Command ::= <DIAMETER-Header: 9999999>
>>                         { User-Name *Host-Name }
>>                         * [ AVP ]
>>                         ? < Integrity-Check-Vector >
>>
>>    The command defined by the preceding grammar MUST begin with a
>>    DIAMETER header, with the command code Id set to 9999999.  There
>>    follows a User-Name AVP, zero or more Host-Name AVPs and zero or
>>    more arbitrary other AVPs (but not User-Name, Host-Name or
>>    Integrity-Check-Vector AVPs).

Here 'AVP' could be anything (vendor specified or otherwise)  BUT the
requirement is that the optional AVP rule cannot include AVPs otherwise
specified in REQUIRED or FIXED fields.  That allows you to write rules
for AVPs which can only occur once, or have to occur in a particular
sequence.

Erik





From owner-aaa-bof@merit.edu  Wed Jan 10 11:28:38 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20627
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 11:28:37 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id E866E5DDF6; Wed, 10 Jan 2001 11:27:58 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id C58CF5DDF0; Wed, 10 Jan 2001 11:27:58 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 152B65DDF6
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 11:27:57 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08559;
	Wed, 10 Jan 2001 08:27:55 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA22942;
	Wed, 10 Jan 2001 08:27:53 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA22696;
	Wed, 10 Jan 2001 08:16:28 -0800 (PST)
Date: Wed, 10 Jan 2001 08:12:51 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Proposed change to DIAMETER header
To: diameter@diameter.org, aaa-wg@merit.edu
Cc: Pat.Calhoun@eng.sun.com
Message-ID: <Roam.SIMC.2.0.6.979143171.3363.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

All,

The method the protocol is currently specified, it requires that an
implementation walk through each AVP, looking for the ICV AVP in order to
perform the necessary replay and authentication checks. What this means is
that there is a significant amount of work required to ensure that the packet
is in fact authentic. This does not bode well for denial of service attacks.

So I would like to propose adding the ICV-Offset to the DIAMETER header, as
shown below:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |RADIUS PCC=254 |  Flags  | Ver |         Message Length        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          Identifier                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Command-Code                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                           Vendor-ID                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          ICV-Offset                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  AVPs ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-

[...]

[ed: and something like (actual words will change):]

ICV-Offset
	The ICV-Offset contains the number of octets from the start
of the DIAMETER header where the ICV AVP can be found. When the ICV
is computed, this field MUST be set to zero. If no ICV was added to
the packet, the value of the ICV-Offset field MUST be zero.

The above change makes it MUCH easier for implementations to authenticate
the packet before parsing through all AVPs in the message.

Do people think this is a worthwhile change? I believe this will make the
protocol less prone to denial of service attacks.

Thanks,

PatC




From owner-aaa-bof@merit.edu  Wed Jan 10 11:28:49 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20648
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 11:28:48 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id A10005DE19; Wed, 10 Jan 2001 11:27:58 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 8E4175DE05; Wed, 10 Jan 2001 11:27:58 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id A32C65DDF0
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 11:27:56 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08558
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 08:27:54 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA22946
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 08:27:54 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA22447
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 08:05:43 -0800 (PST)
Date: Wed, 10 Jan 2001 08:02:07 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: test
To: aaa-wg@merit.edu
Message-ID: <Roam.SIMC.2.0.6.979142527.4329.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

I think I've been dropped from the list, this is a test.

PatC




From owner-aaa-bof@merit.edu  Wed Jan 10 11:28:58 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20664
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 11:28:58 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 66EB05DDF0; Wed, 10 Jan 2001 11:28:18 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 729555DE04; Wed, 10 Jan 2001 11:28:02 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 16F9D5DE33
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 11:27:58 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06943
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 08:27:57 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA22957;
	Wed, 10 Jan 2001 08:27:56 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA21891;
	Wed, 10 Jan 2001 07:36:51 -0800 (PST)
Date: Wed, 10 Jan 2001 07:33:15 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: diameter grammar proposal
To: Erik Guttman <erik.guttman@sun.com>
Cc: pat.calhoun@eng.sun.com, aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <014a01c07b15$d64d6560$5f8e9d81@stag.Germany.Sun.COM>
Message-ID: <Roam.SIMC.2.0.6.979140795.29983.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

>I propose the following section be added to the DIAMETER base spec.
>This will allow us to specify DIAMETER in a more formal way.  This is
>unfortunately not as formal as a BNF would be, but DIAMETER messages
>allow for arbitrary ordering of many elements.   Still, we need to
>be able to specify that some elements may appear only once, and some
>have to appear in fixed positions.  I believe this grammar suffices
>to do this.  Please send comments.

Here are my two cents.

I actually really like Erik's proposal. For the most part, the dictionary and
how messages are defined in the protocol specs are two separate issues, and I
am not sure why we've decided to combine the two. 

The proposal below is much richer than today's spec, since it allows DIAMETER
to defined the message set, while providing information on the number of
AVPs that may (or MUST) be present in the message. This type of information
is present in RADIUS, and is really lacking in DIAMETER.

So here is my proposal. Come out with draft-ietf-aaa-diameter-*00.txt as a WG
work item, with the proposed grammar below. Have the WG work out the details
of data model, and consider whether the message definition in the specs must
follow the accepted grammar. If need be, updated the spoecs as *01.txt.

The reason why I want this done is that there is a bakeoff coming up in 1.5
months, and some of us really want specs to write against. As you know, the
grammar used does not affect the on-the-wire protocol, so this does not affect
the bakeoff.

Comments?

PatC
>
>(Randy, does this hold water?)
>
>Erik
>---------------------------------------------------------------------
>
>1.3 Notation
>
>   The DIAMETER protocol is composed of messages which have three
>   components - a message header, a command code and a set of AVPs.
>   Each message type is distinguished by a single command code.
>   Command are specified using the following notation.
>
>     Command-Code-Name ::= <DIAMETER-Header: #>
>                          { qual AVP }
>                          qual [ qual AVP ]
>                          qual < AVP >
>
>   The symbol # will be replaced by the command Id which is to be
>   placed in the message header.  The symbol AVP MAY be replaced
>   by the names of any specific AVP.  
> 
>   Elements surrounded by less than, greater than '<' and '>' are
>   FIXED in sequence.   For example, the DIAMETER header MUST
>   precede all AVPs.
>
>   Elements surrounded by set brackets '{' and '}' are REQUIRED
>   to be present in the message.  They MAY be in any order within
>   the message provided they do not violate order imposed by message
>   fixed elements in the grammar (which are defined between '<' 
>   and '>' brackets.)
>
>   Elements surrounded by square brackets '[' and ']' are OPTIONAL.
>   AVPs which are listed in this section MAY be included in the
>   message, in any order, provided they do not violate order imposed
>   by fixed message elements in the grammar.  AVPs listed in FIXED
>   or REQUIRED sections MUST NOT be considered OPTIONAL as well.  
>   An AVP required to appear once in one section MUST NOT, therefor,
>   be included as the result of an 'OPTIONAL AVP' rule.
>
>   The token 'qual' can be the following:
>     
>     omitted    One instance of the following entry is required.
>      '*'       Zero or more instances of the following entry are 
>                required.
>      '+'       One or more of instances of the following entry
>                are required.
>      '?'       Zero or one of instances of the following entry
>                are required.
> 
>     Example-Command ::= <DIAMETER-Header: 9999999>
>                        { User-Name *Host-Name }
>                        * [ AVP ]
>                        ? < Integrity-Check-Vector >
>
>   The command defined by the preceding grammar MUST begin with a
>   DIAMETER header, with the command code Id set to 9999999.  There
>   follows a User-Name AVP, zero or more Host-Name AVPs and zero or
>   more arbitrary other AVPs (but not User-Name, Host-Name or 
>   Integrity-Check-Vector AVPs).  The REQUIRED and OPTIONAL AVPs
>   can be permuted into any order, provided that none of them come 
>   before the Header. 
>
>   DIAMETER messages which violate the grammar defined for the
>   command code are considered malformed and are rejected.  See
>   Section 5.0.




From owner-aaa-bof@merit.edu  Wed Jan 10 11:48:50 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21090
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 11:48:48 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 817C55DE03; Wed, 10 Jan 2001 11:45:39 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 6B1465DE1D; Wed, 10 Jan 2001 11:45:39 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 2776D5DE03
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 11:45:38 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19440;
	Wed, 10 Jan 2001 08:45:37 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA26813;
	Wed, 10 Jan 2001 08:45:37 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA23376;
	Wed, 10 Jan 2001 08:45:35 -0800 (PST)
Date: Wed, 10 Jan 2001 08:41:58 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: Section 2.2.5
To: aaa-wg@merit.edu, diameter@diameter.org
Message-ID: <Roam.SIMC.2.0.6.979144918.10877.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Does anyone see why section 2.2.5 (tandard DIAMETER Extension AVPs)needs to be
in the base protocol? It is problematic, since if some of the extensions do
not go through IESG at the same time, the base protocol *could* become
obsolete.

Anyone object to my removing it?

PatC




From owner-aaa-bof@merit.edu  Wed Jan 10 12:43:06 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22250
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 12:43:05 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id A63815DE0A; Wed, 10 Jan 2001 12:42:35 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 967555DE04; Wed, 10 Jan 2001 12:42:35 -0500 (EST)
Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110])
	by segue.merit.edu (Postfix) with ESMTP id BCB495DDFD
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 12:42:34 -0500 (EST)
Received: from Interlinknetworks.com (unknown [198.108.5.3])
	by aaa.interlinknetworks.com (Postfix) with ESMTP
	id C14E073; Wed, 10 Jan 2001 12:42:41 -0500 (EST)
Message-ID: <3A5C9F2B.5A969021@Interlinknetworks.com>
Date: Wed, 10 Jan 2001 12:43:07 -0500
From: David Spence <DSpence@Interlinknetworks.com>
Organization: Interlink Networks, Inc.
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Cc: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>,
        Erik.Guttman@germany.sun.com, aaa-wg@merit.edu
Subject: Re: Choice of Data Model SMI vs XML vs. UML
References: <Roam.SIMC.2.0.6.979095021.7143.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat Calhoun wrote:
> 
> > What, then,
> > would it mean if the Framed-IPX-Network and Framed-AppleTalk-Network AVPs
> > were included in the same message?  My problem with the BNF is that it
> > appears to specify permissible messages but does not.  RADIUS, at least,
> > does not make that pretension.
> 
> I actually do not see why one cannot run both IPX and Appletalk over the same
> PPP connection. Am I missing something fundamental?
>...

Well, of course, you're right.  But in some ways it underlines the problem,
namely, that there isn't any model that says one way or the other. 

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



From owner-aaa-bof@merit.edu  Wed Jan 10 12:56:30 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22444
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 12:56:30 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 016125DE29; Wed, 10 Jan 2001 12:56:12 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id DF0FF5DE51; Wed, 10 Jan 2001 12:56:11 -0500 (EST)
Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110])
	by segue.merit.edu (Postfix) with ESMTP id 0F4015DE29
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 12:56:11 -0500 (EST)
Received: from Interlinknetworks.com (unknown [198.108.5.3])
	by aaa.interlinknetworks.com (Postfix) with ESMTP
	id B9C3A73; Wed, 10 Jan 2001 12:56:17 -0500 (EST)
Message-ID: <3A5CA25B.97E37802@Interlinknetworks.com>
Date: Wed, 10 Jan 2001 12:56:43 -0500
From: David Spence <DSpence@Interlinknetworks.com>
Organization: Interlink Networks, Inc.
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: gwz@cisco.com
Cc: Erik Guttman <Erik.Guttman@germany.sun.com>,
        Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>,
        Pat.Calhoun@eng.sun.com, aaa-wg@merit.edu
Subject: Re: Choice of Data Model SMI vs XML vs. UML
References: <NDBBIHMPILAAGDHPCIOPCECDDBAA.gwz@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:

>... 
> > and so the successor to RADIUS should provide
> > the best platform for future expansion that we can.  It may be argued that
> > the NASREQ application is simple enough that data modeling is unnecessary,
> > but I fear that won't always be the case.  You ought to be able
> > to encompass
> > more services in the future, such as DSL, broadband, and LAN access.
> 
> In the future?  RADIUS (or bizarre, usually proprietary, variants thereof)
> is being used for these things (and more) right now.

Precisely!  But not in a standard way.  And while it isn't in our charter to
standardize those things now, we are creating the framework within which
future standardization will proceed.  The point was that the supposed
simplicity of RADIUS cannot be used as an argument that data modeling is not
necessary. 

> 
> > Without data modeling, things are going to get really messy.
> 
> They already have, some time ago.  We _do not_ need to spend another three
> years blathering about silver bullets.

Agreed.

>... 

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



From owner-aaa-bof@merit.edu  Wed Jan 10 12:57:49 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22498
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 12:57:49 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 2279A5DE5B; Wed, 10 Jan 2001 12:57:35 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 108C95DE51; Wed, 10 Jan 2001 12:57:35 -0500 (EST)
Received: from localhost.ipunplugged.com (unknown [195.42.212.161])
	by segue.merit.edu (Postfix) with ESMTP id 8BBB85DE16
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 12:57:33 -0500 (EST)
Received: from fredrikj (c8.local.ipunplugged.com [192.168.4.207])
	by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id SAA07513;
	Wed, 10 Jan 2001 18:58:30 +0100
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Pat Calhoun" <Pat.Calhoun@Eng.Sun.COM>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: RE: Section 2.2.5
Date: Wed, 10 Jan 2001 18:59:58 +0100
Message-ID: <MJEMJBGGCLLDLFFAHLJKGENOCEAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <Roam.SIMC.2.0.6.979144918.10877.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I agree, remove it or perhaps leave something like.

2.2.5 Additional DIAMETER Extension AVPs
	Additional AVPs may be defined in other DIAMETER Extensions. These may be
Extension specific or may add 	some additional feature to the DIAMETER
protocol as a whole. However these are not mandatory for the 	proper hanling
of the base protocol. For more information see respective DIAMETER Extension
document.

/Fredrik

>-----Original Message-----
>From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
>Of Pat Calhoun
>Sent: den 10 januari 2001 17:42
>To: aaa-wg@merit.edu; diameter@diameter.org
>Subject: Section 2.2.5
>
>
>Does anyone see why section 2.2.5 (tandard DIAMETER Extension
>AVPs)needs to be
>in the base protocol? It is problematic, since if some of the extensions do
>not go through IESG at the same time, the base protocol *could* become
>obsolete.
>
>Anyone object to my removing it?
>
>PatC
>




From owner-aaa-bof@merit.edu  Wed Jan 10 13:04:08 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22645
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 13:04:08 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 4D9755DE1A; Wed, 10 Jan 2001 13:01:41 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 39E525DE16; Wed, 10 Jan 2001 13:01:41 -0500 (EST)
Received: from cisco.com (titans.cisco.com [161.44.216.10])
	by segue.merit.edu (Postfix) with ESMTP id 157055DE1A
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 13:01:39 -0500 (EST)
Received: from titans.cisco.com (titans.cisco.com [161.44.216.10])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA07632;
	Wed, 10 Jan 2001 13:01:06 -0500 (EST)
Date: Wed, 10 Jan 2001 13:01:06 -0500 (EST)
From: Mark Eklund <meklund@cisco.com>
To: Erik Guttman <erik.guttman@sun.com>
Cc: aaa-wg@merit.edu, Randy Bush <randy@psg.com>
Subject: Re: diameter grammar proposal
In-Reply-To: <00e201c07b04$8d162be0$5f8e9d81@stag.Germany.Sun.COM>
Message-ID: <Pine.GSO.4.21.0101100950070.6033-100000@titans.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

A few questions/comments.

1. I am used to seeing qualifiers after the argument like in
regular expressions.  For example Host-Name* instead of
*Host-Name.  This is a personal preference.

2. Why do you need the optional brackets [] when you have the
'*' and '?' operators.  I.E. what is the difference in
*[Host-Name] and *Host-Name?

3. Do you plan to define Grouped-AVP in the specifications?

-mark

On Wed, 10 Jan 2001, Erik Guttman wrote:

> 
> 
> Folks,
> 
> I propose the following section be added to the DIAMETER base spec.
> This will allow us to specify DIAMETER in a more formal way.  This is
> unfortunately not as formal as a BNF would be, but DIAMETER messages
> allow for arbitrary ordering of many elements.   Still, we need to
> be able to specify that some elements may appear only once, and some
> have to appear in fixed positions.  I believe this grammar suffices
> to do this.  Please send comments.
> 
> (Randy, does this hold water?)
> 
> Erik
> ---------------------------------------------------------------------
> 
> 1.3 Notation
> 
>    The DIAMETER protocol is composed of messages which have three
>    components - a message header, a command code and a set of AVPs.
>    Each message type is distinguished by a single command code.
>    Command are specified using the following notation.
> 
>      Command-Code-Name ::= <DIAMETER-Header: #>
>                           { qual AVP }
>                           qual [ qual AVP ]
>                           qual < AVP >
> 
>    The symbol # will be replaced by the command Id which is to be
>    placed in the message header.  The symbol AVP MAY be replaced
>    by the names of any specific AVP.  
>  
>    Elements surrounded by less than, greater than '<' and '>' are
>    FIXED in sequence.   For example, the DIAMETER header MUST
>    precede all AVPs.
> 
>    Elements surrounded by set brackets '{' and '}' are REQUIRED
>    to be present in the message.  They MAY be in any order within
>    the message provided they do not violate order imposed by message
>    fixed elements in the grammar (which are defined between '<' 
>    and '>' brackets.)
> 
>    Elements surrounded by square brackets '[' and ']' are OPTIONAL.
>    AVPs which are listed in this section MAY be included in the
>    message, in any order, provided they do not violate order imposed
>    by fixed message elements in the grammar.  AVPs listed in FIXED
>    or REQUIRED sections MUST NOT be considered OPTIONAL as well.  
>    An AVP required to appear once in one section MUST NOT, therefor,
>    be included as the result of an 'OPTIONAL AVP' rule.
> 
>    The token 'qual' can be the following:
>      
>      omitted    One instance of the following entry is required.
>       '*'       Zero or more instances of the following entry are 
>                 required.
>       '+'       One or more of instances of the following entry
>                 are required.
>       '?'       Zero or one of instances of the following entry
>                 are required.
>  
>      Example-Command ::= <DIAMETER-Header: 9999999>
>                         { User-Name *Host-Name }
>                         * [ AVP ]
>                         ? < Integrity-Check-Vector >
> 
>    The command defined by the preceding grammar MUST begin with a
>    DIAMETER header, with the command code Id set to 9999999.  There
>    follows a User-Name AVP, zero or more Host-Name AVPs and zero or
>    more arbitrary other AVPs (but not User-Name, Host-Name or 
>    Integrity-Check-Vector AVPs).  The REQUIRED and OPTIONAL AVPs
>    can be permuted into any order, provided that none of them come 
>    before the Header. 
> 
>    DIAMETER messages which violate the grammar defined for the
>    command code are considered malformed and are rejected.  See
>    Section 5.0.
> 
> 
> 
> 
> 
> 






From owner-aaa-bof@merit.edu  Wed Jan 10 13:08:34 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22700
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 13:08:34 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id A19595DE04; Wed, 10 Jan 2001 13:08:12 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 8FBEC5DDFD; Wed, 10 Jan 2001 13:08:12 -0500 (EST)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by segue.merit.edu (Postfix) with ESMTP id 3CA995DDA5
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 13:08:11 -0500 (EST)
Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f0AI88K09847;
	Wed, 10 Jan 2001 12:08:08 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id f0AI4jC25355;
	Wed, 10 Jan 2001 12:04:45 -0600 (CST)
Received: from qpop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA20579; Wed, 10 Jan 2001 12:08:07 -0600 (CST)
Received: from kev (busam66.berkeley.us.am.ericsson.se [138.85.159.216])
	by qpop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id MAA07119;
	Wed, 10 Jan 2001 12:08:04 -0600 (CST)
Message-ID: <002501c07b30$452d0980$91aea8c0@erilab.com>
From: "Kevin Purser" <kevin.purser@ericsson.com>
To: "Erik Guttman" <erik.guttman@sun.com>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
References: <011d01c07b06$a545a900$5f8e9d81@stag.Germany.Sun.COM>
Subject: Re: proposed new section for DIAMETER base specification
Date: Wed, 10 Jan 2001 10:07:59 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Erik/All,

Just a quick comment... (inline)

>
>       0x10 MUST be zero - this flag bit is reserved for future use.
>       0x08 MUST be zero - this flag bit is reserved for future use.
>       0x04 ('E' Expect Reply) The message solicits a response.
>       0x02 ('I' Interrogation) The message is a Query or a Reply.
>       0x01 ('R' Response) The message is a response another message.
>
>       These flags are set depending on the command code used in a
>       DIAMETER message.  This enables the type of message to be
>       interpreted, even if the specific command code is not recognized.
>
>       Command Type   Flags Set
>        Indication      - - -
>        Request         E - -
>        Answer          E - R
>        Query           E I -
>        Reply           E I R
>

It seems a bit odd to set the "Expect Reply" bit in a Reply message, and
probably an Answer message as well, since neither of which directly solicit
a Reply.


>       A DIAMETER node MUST NOT set these flags in any other combination.
>       A DIAMETER node receiving a message in which these flags are not
>       set appropriately SHOULD NOT reject the message for this reason,
>       but MAY log the event for diagnosis.
>
>
>




From owner-aaa-bof@merit.edu  Wed Jan 10 13:56:26 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24246
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 13:56:26 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id D32F95DE11; Wed, 10 Jan 2001 13:56:07 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id C3A615DE00; Wed, 10 Jan 2001 13:56:07 -0500 (EST)
Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9])
	by segue.merit.edu (Postfix) with ESMTP id ACE3C5DDFF
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 13:56:06 -0500 (EST)
Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2])
	by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id OAA08397;
	Wed, 10 Jan 2001 14:51:56 -0500
Received: from mjones (mjones.bridgewatersys.com [192.168.150.32])
	by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id NAA15824;
	Wed, 10 Jan 2001 13:56:24 -0500 (EST)
From: "Mark Jones" <mjones@bridgewatersystems.com>
To: "Erik Guttman" <erik.guttman@sun.com>, <aaa-wg@merit.edu>
Subject: RE: diameter grammar proposal
Date: Wed, 10 Jan 2001 14:03:05 -0500
Message-ID: <008a01c07b37$f6836d80$2096a8c0@bridgewatersys.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <00e201c07b04$8d162be0$5f8e9d81@stag.Germany.Sun.COM>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Erik,

Aren't the {} and [] brackets redundant given the 'qual' token definitions?

i.e.
	'*'  = Zero or more instances MAY be present in the packet = OPTIONAL AVP
	'+'  = At least one instance MUST be present in the packet = MANDATORY AVP
	'?'  = Zero or one instances MAY be present in the packet  = OPTIONAL AVP
   omitted = Exactly one instance MUST be present in the packet  = MANDATORY
AVP

Regards,
       Mark

> -----Original Message-----
> From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
> Of Erik Guttman
> Sent: January 10, 2001 7:55 AM
> To: aaa-wg@merit.edu; Randy Bush
> Cc: Erik Guttman
> Subject: diameter grammar proposal
>
>
>
>
> Folks,
>
> I propose the following section be added to the DIAMETER base spec.
> This will allow us to specify DIAMETER in a more formal way.  This is
> unfortunately not as formal as a BNF would be, but DIAMETER messages
> allow for arbitrary ordering of many elements.   Still, we need to
> be able to specify that some elements may appear only once, and some
> have to appear in fixed positions.  I believe this grammar suffices
> to do this.  Please send comments.
>
> (Randy, does this hold water?)
>
> Erik
> ---------------------------------------------------------------------
>
> 1.3 Notation
>
>    The DIAMETER protocol is composed of messages which have three
>    components - a message header, a command code and a set of AVPs.
>    Each message type is distinguished by a single command code.
>    Command are specified using the following notation.
>
>      Command-Code-Name ::= <DIAMETER-Header: #>
>                           { qual AVP }
>                           qual [ qual AVP ]
>                           qual < AVP >
>
>    The symbol # will be replaced by the command Id which is to be
>    placed in the message header.  The symbol AVP MAY be replaced
>    by the names of any specific AVP.
>
>    Elements surrounded by less than, greater than '<' and '>' are
>    FIXED in sequence.   For example, the DIAMETER header MUST
>    precede all AVPs.
>
>    Elements surrounded by set brackets '{' and '}' are REQUIRED
>    to be present in the message.  They MAY be in any order within
>    the message provided they do not violate order imposed by message
>    fixed elements in the grammar (which are defined between '<'
>    and '>' brackets.)
>
>    Elements surrounded by square brackets '[' and ']' are OPTIONAL.
>    AVPs which are listed in this section MAY be included in the
>    message, in any order, provided they do not violate order imposed
>    by fixed message elements in the grammar.  AVPs listed in FIXED
>    or REQUIRED sections MUST NOT be considered OPTIONAL as well.
>    An AVP required to appear once in one section MUST NOT, therefor,
>    be included as the result of an 'OPTIONAL AVP' rule.
>
>    The token 'qual' can be the following:
>
>      omitted    One instance of the following entry is required.
>       '*'       Zero or more instances of the following entry are
>                 required.
>       '+'       One or more of instances of the following entry
>                 are required.
>       '?'       Zero or one of instances of the following entry
>                 are required.
>
>      Example-Command ::= <DIAMETER-Header: 9999999>
>                         { User-Name *Host-Name }
>                         * [ AVP ]
>                         ? < Integrity-Check-Vector >
>
>    The command defined by the preceding grammar MUST begin with a
>    DIAMETER header, with the command code Id set to 9999999.  There
>    follows a User-Name AVP, zero or more Host-Name AVPs and zero or
>    more arbitrary other AVPs (but not User-Name, Host-Name or
>    Integrity-Check-Vector AVPs).  The REQUIRED and OPTIONAL AVPs
>    can be permuted into any order, provided that none of them come
>    before the Header.
>
>    DIAMETER messages which violate the grammar defined for the
>    command code are considered malformed and are rejected.  See
>    Section 5.0.
>
>
>
>
>
>




From owner-aaa-bof@merit.edu  Wed Jan 10 16:35:31 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27664
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 16:35:30 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id D299E5DE24; Wed, 10 Jan 2001 16:34:16 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id C116B5DE05; Wed, 10 Jan 2001 16:34:16 -0500 (EST)
Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9])
	by segue.merit.edu (Postfix) with ESMTP id F084A5DDFF
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 16:34:14 -0500 (EST)
Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2])
	by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id RAA09668;
	Wed, 10 Jan 2001 17:29:39 -0500
Received: from mjones (mjones.bridgewatersys.com [192.168.150.32])
	by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id QAA19531;
	Wed, 10 Jan 2001 16:34:08 -0500 (EST)
From: "Mark Jones" <mjones@bridgewatersystems.com>
To: <aaa-wg@merit.edu>, <diameter@diameter.org>
Subject: RE: [diameter] data type modifications to DIAMETER (Fwd)
Date: Wed, 10 Jan 2001 16:40:48 -0500
Message-ID: <008f01c07b4d$ff21d740$2096a8c0@bridgewatersys.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Roam.SIMC.2.0.6.979137833.8097.pcalhoun@nasnfs>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

In DIAMETER, the IPv4 and IPv6 addresses are collapsed into the single
Address datatype where the actual IP version is determined from the length.
The RADIUS and IPv6 draft (draft-aboba-radius-ipv6-04.txt) appears to take a
different approach by using separate AVPs for IPv4 and IPv6 addresses, e.g.
Login-IP-Host and Login-IPv6-Host.

I was considering whether the DIAMETER approach could also applied in
RADIUSv6 since a common approach would simplify the RADIUS-DIAMETER gateway
implementation.

The RADIUSv6 draft does state that IPv4 and IPv6 attributes MAY be included
in the same RADIUS message and the NAS will decide which attributes to use.
However, I see no reason why a DIAMETER or RADIUS packet could not contain
two instances of the same address AVP: one IPv4 and one IPv6 address. The
NAS could still use the same logic to decide which attributes to use for the
session.

Are there any other issues that would prevent a common approach?

Regards,
       Mark

> -----Original Message-----
> From: owner-diameter@diameter.org [mailto:owner-diameter@diameter.org]On
> Behalf Of Pat Calhoun
> Sent: January 10, 2001 9:44 AM
> To: diameter@diameter.org
> Subject: [diameter] data type modifications to DIAMETER (Fwd)
>
>
> FYI
> >----------------Begin Forwarded Message----------------<
>
> Date: Wed, 10 Jan 2001 15:18:52 +0100
> From: "Erik Guttman" <erik.guttman@sun.com>
> Subject: data type modifications to DIAMETER
> To: diameter@diameter.org, aaa-wg@merit.edu
>
>
> As proposed in draft-ietf-aaa-issues-04.txt and
> draft-ietf-aaa-solutions-01.txt section 9.2, I am
> revising the basic data types in DIAMETER.
>
> I do not list all the changes in this document -
> but the implications are the following.
>
>  1. Data type changes:
>
>     Old type        New type
>     ------------    -------------
>     Address         Address
>     Data            OctetString
>     String          OctetString
>     Time            Unsigned32
>     Integer32       Integer32
>     Integer64       Integer64
>     Complex         Grouped
>                     Unsigned32
>                     Unsigned64
>                     Float32
>                     Float64
>                     Float128
>
>  2. Scalar quantities (Ids and so on from AVPs) had Integer32 type.
>     Now they have Unsigned32 type.
>
>  3. String is now one interpretation of an OctetString.
>
>  4. Time is now one interpretation of an Unsigned32 value.
>
>  5. The biggest change is the elimination of the 'Complex' data
>     type.  Now all AVPs have an 'atomic' data type except for
>     Grouped.  Grouped takes as its value a list of AVPs which
>     have to be included (AVP header and all) in exactly the
>     sequence specified.
>
> Implications for DIAMETER implementations:
>
>   The only real change is that Complex data types have been
>   restructured.  Code handling AVPs which were previously of
>   type Complex will have to change.
>
>   Code which handled the previous types will be easily mapped
>   into the new data types (Integer32 -> Unsigned32, Time ->
>   Unsigned32, String -> OctetString)  There are some subtle
>   range checking changes to be made (maybe) since scalars are now
>   Unsigned32 where before they were Integer32.
>
> Rationale:
>
>   See draft-ietf-aaa-issues-04.txt.  In short, there were several
>   problems with the basic types used by DIAMETER.  (1) Some were
>   interpretations (String and Time) not basic scalars.  (2) Some
>   were ambiguous (Integer32 used as an unsigned scalar).  (3) Not
>   including basic types (floats, mostly) makes future expansion
>   hard.  (4) The types specified were incompatible with SMI and
>   SPPI data types. (5) The complex data type made it hard to
>   create a general data model, easily automated parsers and
>   general 'sniffers.'  All AVPs should either have atomic values
>   or a list of AVPs as their values.  (6) The Grouped-AVP was
>   unnecessarily complex. (7) Complex data types required a 'hack'
>   for fixing the length of certain data fields (such as using 16
>   bytes for addresses where they could be 4 bytes long).  This is
>   no longer necessary.
>
> Erik
>
>
>
> >----------------End Forwarded Message----------------<
>
>




From owner-aaa-bof@merit.edu  Wed Jan 10 16:39:22 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27722
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 16:39:21 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id B6BA45DE14; Wed, 10 Jan 2001 16:39:06 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A5DE85DE05; Wed, 10 Jan 2001 16:39:06 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 580D85DDFF
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 16:39:05 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25339;
	Wed, 10 Jan 2001 13:38:58 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA22011;
	Wed, 10 Jan 2001 13:38:57 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA00826;
	Wed, 10 Jan 2001 13:38:55 -0800 (PST)
Date: Wed, 10 Jan 2001 13:35:19 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: RE: [diameter] data type modifications to DIAMETER (Fwd)
To: Mark Jones <mjones@bridgewatersystems.com>
Cc: aaa-wg@merit.edu, diameter@diameter.org
In-Reply-To: "Your message with ID" <008f01c07b4d$ff21d740$2096a8c0@bridgewatersys.com>
Message-ID: <Roam.SIMC.2.0.6.979162519.5304.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

I think that the orignal intent of having a dual purpose AVP was to reduce the
number of AVPs that would have to be defined. Furthermore, the Implementation
Guidelines, which describes the protocol gateway stuff, would have to include
text that describes what to do if an IPv4 was found, as opposed to an IPv6
address.

Are there any others that have any concerns with the dual purpose AVP approach?
 PatC




From owner-aaa-bof@merit.edu  Wed Jan 10 16:55:12 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28096
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 16:55:12 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id A2B665DE1C; Wed, 10 Jan 2001 16:54:44 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 84DD45DE16; Wed, 10 Jan 2001 16:54:44 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id BD2E15DE05
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 16:54:42 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA27484;
	Wed, 10 Jan 2001 13:54:40 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA27098;
	Wed, 10 Jan 2001 13:54:37 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA01183;
	Wed, 10 Jan 2001 13:54:35 -0800 (PST)
Date: Wed, 10 Jan 2001 13:50:59 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: Re: proposed new section for DIAMETER base specification
To: aaa-wg@merit.edu, diameter@diameter.org
Message-ID: <Roam.SIMC.2.0.6.979163459.6071.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


>
> It seems a bit odd to set the "Expect Reply" bit in a Reply message, and
> probably an Answer message as well, since neither of which directly solicit
> a Reply.

Agreed, and the text would actually look like:

----
[...]
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |RADIUS PCC=254 |r r E I R| Ver |         Message Length        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[...]
   Flags
      The Message Flags field is five bits.  The following bits are
      assigned:

         r(eserved) MUST be zero - this flag bit is reserved for future use.
         E(xpected Reply) - The message solicits a response.
         I(nterrogation) - The message is a Query or a Reply.
         R(esponse) - The message is a response another message.

      These flags are set depending on the command code used in a
      DIAMETER message.  This enables the type of message to be
      interpreted, even if the specific command code is not recognized.

      Command Type   Flags Set
      Indication      - - -
      Request         E - -
      Answer          - - R
      Query           E I -
      Reply           - I R

      A DIAMETER node MUST NOT set these flags in any other combination.
      A DIAMETER node receiving a message in which these flags are not
      set appropriately SHOULD NOT reject the message for this reason,
      but MAY log the event for diagnosis.
----

Any objections? This text was in the solutions I-D (or similar text), and no
objections were received. Further, I think that this information is VERY
important for proxies, since they need to know when a message is a request or
a response (especially important when they do not support the extension, but
still wish to route the message).

Of course, there is also the question of removing the PCC or not.

PatC




From owner-aaa-bof@merit.edu  Wed Jan 10 16:55:23 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28134
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 16:55:22 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id C3DA65DDFF; Wed, 10 Jan 2001 16:54:46 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 89A665DE2F; Wed, 10 Jan 2001 16:54:46 -0500 (EST)
Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9])
	by segue.merit.edu (Postfix) with ESMTP id 3BC6E5DDFF
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 16:54:42 -0500 (EST)
Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2])
	by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id RAA09797;
	Wed, 10 Jan 2001 17:50:14 -0500
Received: from mjones (mjones.bridgewatersys.com [192.168.150.32])
	by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id QAA19930;
	Wed, 10 Jan 2001 16:54:43 -0500 (EST)
From: "Mark Jones" <mjones@bridgewatersystems.com>
To: "Pat Calhoun" <Pat.Calhoun@Eng.Sun.COM>
Cc: <aaa-wg@merit.edu>, <diameter@diameter.org>
Subject: RE: [diameter] data type modifications to DIAMETER (Fwd)
Date: Wed, 10 Jan 2001 17:01:24 -0500
Message-ID: <009201c07b50$df796950$2096a8c0@bridgewatersys.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Roam.SIMC.2.0.6.979162519.5304.pcalhoun@nasnfs>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat,

I understand the rationale of the dual purpose AVP and have no concerns
about its use in DIAMETER. I was just suggesting that we consider using the
same approach in RADIUSv6 to simplify the gateway implementation.

Regards,
       Mark

> -----Original Message-----
> From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
> Of Pat Calhoun
> Sent: January 10, 2001 4:35 PM
> To: Mark Jones
> Cc: aaa-wg@merit.edu; diameter@diameter.org
> Subject: RE: [diameter] data type modifications to DIAMETER (Fwd)
>
>
> I think that the orignal intent of having a dual purpose AVP was
> to reduce the
> number of AVPs that would have to be defined. Furthermore, the
> Implementation
> Guidelines, which describes the protocol gateway stuff, would
> have to include
> text that describes what to do if an IPv4 was found, as opposed to an IPv6
> address.
>
> Are there any others that have any concerns with the dual purpose
> AVP approach?
>  PatC
>
>
>




From owner-aaa-bof@merit.edu  Wed Jan 10 16:57:22 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28435
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 16:57:22 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id D9A815DE1D; Wed, 10 Jan 2001 16:57:06 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id C83085DE16; Wed, 10 Jan 2001 16:57:06 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 7DE725DE05
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 16:57:05 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA28407;
	Wed, 10 Jan 2001 13:56:53 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA27801;
	Wed, 10 Jan 2001 13:56:48 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA01237;
	Wed, 10 Jan 2001 13:56:46 -0800 (PST)
Date: Wed, 10 Jan 2001 13:53:08 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: RE: [diameter] data type modifications to DIAMETER (Fwd)
To: Mark Jones <mjones@bridgewatersystems.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>, aaa-wg@merit.edu,
        diameter@diameter.org
In-Reply-To: "Your message with ID" <009201c07b50$df796950$2096a8c0@bridgewatersys.com>
Message-ID: <Roam.SIMC.2.0.6.979163588.25585.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Oh, I see. You were questioning whether RADIUSv6 should change. That may be
harder to do, unless these new attributes have a new type, perhaps
Dual-Address, instead of Address.

PatC
> Pat,
> 
> I understand the rationale of the dual purpose AVP and have no concerns
> about its use in DIAMETER. I was just suggesting that we consider using the
> same approach in RADIUSv6 to simplify the gateway implementation.
> 
> Regards,
>        Mark
> 
> > -----Original Message-----
> > From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
> > Of Pat Calhoun
> > Sent: January 10, 2001 4:35 PM
> > To: Mark Jones
> > Cc: aaa-wg@merit.edu; diameter@diameter.org
> > Subject: RE: [diameter] data type modifications to DIAMETER (Fwd)
> >
> >
> > I think that the orignal intent of having a dual purpose AVP was
> > to reduce the
> > number of AVPs that would have to be defined. Furthermore, the
> > Implementation
> > Guidelines, which describes the protocol gateway stuff, would
> > have to include
> > text that describes what to do if an IPv4 was found, as opposed to an IPv6
> > address.
> >
> > Are there any others that have any concerns with the dual purpose
> > AVP approach?
> >  PatC
> >
> >
> >
> 





From owner-aaa-bof@merit.edu  Wed Jan 10 17:04:41 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28616
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 17:04:40 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id E61575DEA1; Wed, 10 Jan 2001 17:03:33 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id D44145DE9E; Wed, 10 Jan 2001 17:03:33 -0500 (EST)
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by segue.merit.edu (Postfix) with SMTP id 8A2C85DE47
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 17:03:32 -0500 (EST)
Received: (qmail 27395 invoked by uid 500); 10 Jan 2001 22:04:49 -0000
Date: Wed, 10 Jan 2001 16:04:49 -0600
From: David Frascone <dave@frascone.com>
To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Cc: aaa-wg@merit.edu, diameter@diameter.org
Subject: Re: proposed new section for DIAMETER base specification
Message-ID: <20010110160449.H26737@newman.frascone.com>
Mail-Followup-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>, aaa-wg@merit.edu,
	diameter@diameter.org
References: <Roam.SIMC.2.0.6.979163459.6071.pcalhoun@nasnfs>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Roam.SIMC.2.0.6.979163459.6071.pcalhoun@nasnfs>; from Pat.Calhoun@Eng.Sun.COM on Wed, Jan 10, 2001 at 01:50:59PM -0800
X-encrypt-payload: no
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

I don't see any need for the PCC now that Diameter is *not* running over UDP.

> Of course, there is also the question of removing the PCC or not.



From owner-aaa-bof@merit.edu  Wed Jan 10 18:18:51 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03887
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 18:18:50 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 262025DDE6; Wed, 10 Jan 2001 18:16:17 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 11D525DE25; Wed, 10 Jan 2001 18:16:17 -0500 (EST)
Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9])
	by segue.merit.edu (Postfix) with ESMTP id 4647D5DDE6
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 18:16:15 -0500 (EST)
Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2])
	by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id TAA10357;
	Wed, 10 Jan 2001 19:12:02 -0500
Received: from mjones (mjones.bridgewatersys.com [192.168.150.32])
	by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id SAA01579;
	Wed, 10 Jan 2001 18:16:31 -0500 (EST)
From: "Mark Jones" <mjones@bridgewatersystems.com>
To: "Pat Calhoun" <Pat.Calhoun@eng.sun.com>
Cc: <aaa-wg@merit.edu>, <diameter@diameter.org>
Subject: RE: [diameter] data type modifications to DIAMETER (Fwd)
Date: Wed, 10 Jan 2001 18:23:12 -0500
Message-ID: <009901c07b5c$4cc5e820$2096a8c0@bridgewatersys.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Roam.SIMC.2.0.6.979163588.25585.pcalhoun@nasnfs>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat,

> Oh, I see. You were questioning whether RADIUSv6 should change.
> That may be harder to do, unless these new attributes have a new type,
> perhaps Dual-Address, instead of Address.
>

Would new RADIUS attributes for IPv6 addresses still be required if RADIUSv6
were to adopt the dual purpose AVP approach? If, as suggested by the
RADIUSv6 spec, the RADIUS packet contained both IPv4 and IPv6 AVPs, the NAS
can still distinguish the IPv4/IPv6 addresses by their length and so can
choose the appropriate instance of the address AVP depending on whether its
client is IPv4 or IPv6.

If there is not a common approach to IPv4/IPv6 address encoding, the
DIAMETER-RADIUS gateway must translate, for example, a DIAMETER
Login-IP-Host AVP to a RADIUS Login-IP-Host or Login-IPv6-Host AVP depending
on its length. Not complex. Just tedious.

Regards,
       Mark





From owner-aaa-bof@merit.edu  Wed Jan 10 18:49:03 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04810
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 18:49:02 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 6A8325DE2B; Wed, 10 Jan 2001 18:47:07 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 593CF5DE25; Wed, 10 Jan 2001 18:47:07 -0500 (EST)
Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9])
	by segue.merit.edu (Postfix) with ESMTP id 78FC55DE00
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 18:47:05 -0500 (EST)
Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2])
	by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id TAA10504
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 19:42:55 -0500
Received: from mjones (mjones.bridgewatersys.com [192.168.150.32])
	by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id SAA01888
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 18:47:24 -0500 (EST)
From: "Mark Jones" <mjones@bridgewatersystems.com>
To: <aaa-wg@merit.edu>
Subject: RE: [diameter] RE: diameter grammar proposal
Date: Wed, 10 Jan 2001 18:54:04 -0500
Message-ID: <009f01c07b60$9d22e300$2096a8c0@bridgewatersys.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Roam.SIMC.2.0.6.979163815.22211.pcalhoun@nasnfs>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat,

> If we were to make the above changes, would you object to this
> ABNF format in the -00 spec?
>

No objections here. As you point out, the bake-off is coming up fast so lets
go with this for the -00 spec.

Regards,
       Mark




From owner-aaa-bof@merit.edu  Wed Jan 10 19:11:09 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05477
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 19:11:09 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 88D2C5DE16; Wed, 10 Jan 2001 19:10:37 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 61A1E5DE05; Wed, 10 Jan 2001 19:10:37 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 1A24A5DE16
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 19:10:36 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA17820;
	Wed, 10 Jan 2001 16:10:33 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA07484;
	Wed, 10 Jan 2001 16:10:33 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA04507;
	Wed, 10 Jan 2001 16:10:24 -0800 (PST)
Date: Wed, 10 Jan 2001 16:06:47 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: RE: [diameter] data type modifications to DIAMETER (Fwd)
To: Mark Jones <mjones@bridgewatersystems.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>, aaa-wg@merit.edu,
        diameter@diameter.org
In-Reply-To: "Your message with ID" <009901c07b5c$4cc5e820$2096a8c0@bridgewatersys.com>
Message-ID: <Roam.SIMC.2.0.6.979171607.28030.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


> Would new RADIUS attributes for IPv6 addresses still be required if RADIUSv6
> were to adopt the dual purpose AVP approach? If, as suggested by the
> RADIUSv6 spec, the RADIUS packet contained both IPv4 and IPv6 AVPs, the NAS
> can still distinguish the IPv4/IPv6 addresses by their length and so can
> choose the appropriate instance of the address AVP depending on whether its
> client is IPv4 or IPv6.
> 
> If there is not a common approach to IPv4/IPv6 address encoding, the
> DIAMETER-RADIUS gateway must translate, for example, a DIAMETER
> Login-IP-Host AVP to a RADIUS Login-IP-Host or Login-IPv6-Host AVP depending
> on its length. Not complex. Just tedious.

But how would you deal with backward compatibility? This seems especially
important given that in a roaming network, you never know whether the home, or
the NAS, support v6.

PatC




From owner-aaa-bof@merit.edu  Wed Jan 10 19:49:52 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07753
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 19:49:52 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 123475DE51; Wed, 10 Jan 2001 19:47:25 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id F0A125DE4B; Wed, 10 Jan 2001 19:47:24 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id D80515DDE8
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 19:47:23 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA26409;
	Wed, 10 Jan 2001 16:47:22 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA17473;
	Wed, 10 Jan 2001 16:47:22 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA05621;
	Wed, 10 Jan 2001 16:47:20 -0800 (PST)
Date: Wed, 10 Jan 2001 16:43:43 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: The Identifier field
To: aaa-wg@merit.edu, diameter@diameter.org
Message-ID: <Roam.SIMC.2.0.6.979173823.19029.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

[ed: I hate this cross-posting, but it seems necessary :(]

Tony brought up a question some time ago as to the usefulness of the
Identifier field. I believe that no justification was provided at the time for
the existence of the field. In the process of editing the base protocol, it
came to me the reason why such a field may be required.

Assume for a moment that we are a NAS, and that two authorization messages are
sent for the same user (let's assume for the moment that these are for
different services). When either of the responses are received, how would the
NAS know to match request and the response. The obvious answer is to require
that the NAS walk through the whole message, looking for clues (e.g. service
type). This is rather cumbersome.

The Identifier field DOES provide such a hint. However, we need to make sure
that the Identifier field IS NOT modified in transit towards the home server
(as it is done in RADIUS), because there really is no need to do so, and it
does complicate the protocol. 

So I propose keeping the Identifier field, but adding text that it is ONLY of
use to the initiator of a request to match up the response.

Does this make sense?

PatC




From owner-aaa-bof@merit.edu  Wed Jan 10 20:00:15 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07891
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 20:00:15 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 713625DE4B; Wed, 10 Jan 2001 19:59:50 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 4F80F5DE55; Wed, 10 Jan 2001 19:59:50 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 0DCA85DE4B
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 19:59:49 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10546;
	Wed, 10 Jan 2001 16:59:48 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA19879;
	Wed, 10 Jan 2001 16:59:47 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA05879;
	Wed, 10 Jan 2001 16:59:45 -0800 (PST)
Date: Wed, 10 Jan 2001 16:56:08 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: Capabilities Negotiation and proxies
To: aaa-wg@merit.edu, diameter@diameter.org
Message-ID: <Roam.SIMC.2.0.6.979174568.27364.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

All,

As discussed a few days ago, a proxy MAY wish to proxy ANY type of message,
regardless of the extension. Therefore, the current text in the base protocol
does not allow this behavior since it would require that proxies advertise ALL
possible extensions.

Therefore, I am proposing adding the last paragraph to section 2.5.3.
Furthermore, I believe that ALL messages MUST include the extension ID of the
particular message. The reason being that a proxy would need to identify a
server in the home domain that can handle the message, but it may not recognize
the command.

Comments? Objections? Proposed Text?

PatC

2.5.3  Extension-Id AVP

   The Extension-Id AVP (AVP Code 258) is of type Unsigned32 and is used
   in order to identify a specific DIAMETER extension. This AVP is used
   in the Device-Reboot-Ind message in order to inform the peer what
   extensions are locally supported. The Extension-Id MUST also be present
   in all messages that are defined in a separate DIAMETER specification
   and have an Extension ID assigned.

   Each DIAMETER extension draft MUST have an IANA assigned extension
   Idenfier (see section 8.3). The base protocol does not require an
   Extension-Id since its support is mandatory.

   There MAY be more than one Extension-Id AVP within a DIAMETER
   Device-Reboot-Ind message. The following values are recognized:

      NASREQ              1 [7]
      Strong Security     2 [11]
      Resource Management 3 [29]
      Mobile-IP           4 [10]
      Accounting          5 [15]

      Furthermore, servers acting as Redirect or Proxy servers (see
      Section 6.0) MAY wish to advertise support for ALL possible
      extensions. Such servers are then responsible for finding a
      downstream server that supports the extension of a particular
      message. This is done by including the Extension-Id AVP with a
      value of zero (0).




From owner-aaa-bof@merit.edu  Wed Jan 10 20:12:57 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08137
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 20:12:57 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 77A8D5DE25; Wed, 10 Jan 2001 20:12:41 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 67A405DE05; Wed, 10 Jan 2001 20:12:41 -0500 (EST)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by segue.merit.edu (Postfix) with ESMTP id 247675DDE8
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 20:12:40 -0500 (EST)
Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f0B1BfK24495;
	Wed, 10 Jan 2001 19:11:41 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f0B1BfU01659;
	Wed, 10 Jan 2001 19:11:41 -0600 (CST)
Received: from qpop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id TAA10813; Wed, 10 Jan 2001 19:11:41 -0600 (CST)
Received: from ericsson.com (busam50.berkeley.us.am.ericsson.se [138.85.159.200])
	by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id TAA16150;
	Wed, 10 Jan 2001 19:11:38 -0600 (CST)
Message-ID: <3A5D0286.327AA826@ericsson.com>
Date: Wed, 10 Jan 2001 16:47:02 -0800
From: Tony Johansson <tony.johansson@ericsson.com>
Organization: Ericsson Inc
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Cc: aaa-wg@merit.edu, diameter@diameter.org
Subject: Re: The Identifier field
References: <Roam.SIMC.2.0.6.979173823.19029.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Good point and I think this make sense to keep the Identifier field as state
below.

BR,

/Tony

Pat Calhoun wrote:

> [ed: I hate this cross-posting, but it seems necessary :(]
>
> Tony brought up a question some time ago as to the usefulness of the
> Identifier field. I believe that no justification was provided at the time for
> the existence of the field. In the process of editing the base protocol, it
> came to me the reason why such a field may be required.
>
> Assume for a moment that we are a NAS, and that two authorization messages are
> sent for the same user (let's assume for the moment that these are for
> different services). When either of the responses are received, how would the
> NAS know to match request and the response. The obvious answer is to require
> that the NAS walk through the whole message, looking for clues (e.g. service
> type). This is rather cumbersome.
>
> The Identifier field DOES provide such a hint. However, we need to make sure
> that the Identifier field IS NOT modified in transit towards the home server
> (as it is done in RADIUS), because there really is no need to do so, and it
> does complicate the protocol.
>
> So I propose keeping the Identifier field, but adding text that it is ONLY of
> use to the initiator of a request to match up the response.
>
> Does this make sense?
>
> PatC




From owner-aaa-bof@merit.edu  Wed Jan 10 21:01:51 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09216
	for <aaa-archive@odin.ietf.org>; Wed, 10 Jan 2001 21:01:51 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 22A455DDA8; Wed, 10 Jan 2001 21:00:12 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id DF7155DE05; Wed, 10 Jan 2001 21:00:11 -0500 (EST)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by segue.merit.edu (Postfix) with ESMTP id 64C1C5DDA8
	for <aaa-wg@merit.edu>; Wed, 10 Jan 2001 21:00:08 -0500 (EST)
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0B1xt313997
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 03:59:55 +0200 (EET)
Received: from esebh11nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.1.2) with ESMTP id <Bac158f2351086b63d4@esvir03nok.nokia.com>;
 Thu, 11 Jan 2001 04:00:06 +0200
Received: by esebh11nok with Internet Mail Service (5.5.2652.78)
	id <ZPYM1HMB>; Thu, 11 Jan 2001 04:00:06 +0200
Message-ID: <F3768A6EA461D311A4BD0008C7735E596603FD@beeis01nok>
From: Dongfeng.Jing@nokia.com
To: Pat.Calhoun@Eng.Sun.COM, aaa-wg@merit.edu, diameter@diameter.org
Subject: RE: [diameter] Capabilities Negotiation and proxies
Date: Thu, 11 Jan 2001 03:54:44 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

why the value of Extension_ID can not use a bit of that Unsigned32.
for example :
       NASREQ              1 
       Strong Security     2 
       Resource Management 4 
       Mobile-IP           8 
       Accounting         16  

dongfeng.jing

> -----Original Message-----
> From: ext Pat Calhoun [mailto:Pat.Calhoun@Eng.Sun.COM]
> Sent: 11. January 2001 8:56
> To: aaa-wg@merit.edu; diameter@diameter.org
> Subject: [diameter] Capabilities Negotiation and proxies
> 
> 
> All,
> 
> As discussed a few days ago, a proxy MAY wish to proxy ANY 
> type of message,
> regardless of the extension. Therefore, the current text in 
> the base protocol
> does not allow this behavior since it would require that 
> proxies advertise ALL
> possible extensions.
> 
> Therefore, I am proposing adding the last paragraph to section 2.5.3.
> Furthermore, I believe that ALL messages MUST include the 
> extension ID of the
> particular message. The reason being that a proxy would need 
> to identify a
> server in the home domain that can handle the message, but it 
> may not recognize
> the command.
> 
> Comments? Objections? Proposed Text?
> 
> PatC
> 
> 2.5.3  Extension-Id AVP
> 
>    The Extension-Id AVP (AVP Code 258) is of type Unsigned32 
> and is used
>    in order to identify a specific DIAMETER extension. This 
> AVP is used
>    in the Device-Reboot-Ind message in order to inform the peer what
>    extensions are locally supported. The Extension-Id MUST 
> also be present
>    in all messages that are defined in a separate DIAMETER 
> specification
>    and have an Extension ID assigned.
> 
>    Each DIAMETER extension draft MUST have an IANA assigned extension
>    Idenfier (see section 8.3). The base protocol does not require an
>    Extension-Id since its support is mandatory.
> 
>    There MAY be more than one Extension-Id AVP within a DIAMETER
>    Device-Reboot-Ind message. The following values are recognized:
> 
>       NASREQ              1 [7]
>       Strong Security     2 [11]
>       Resource Management 3 [29]
>       Mobile-IP           4 [10]
>       Accounting          5 [15]
> 
>       Furthermore, servers acting as Redirect or Proxy servers (see
>       Section 6.0) MAY wish to advertise support for ALL possible
>       extensions. Such servers are then responsible for finding a
>       downstream server that supports the extension of a particular
>       message. This is done by including the Extension-Id AVP with a
>       value of zero (0).
> 



From owner-aaa-bof@merit.edu  Thu Jan 11 05:11:13 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28149
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 05:11:13 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 50C0D5DD8C; Thu, 11 Jan 2001 05:10:37 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 31DC35DE0B; Thu, 11 Jan 2001 05:10:37 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id BF6EA5DD8C
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 05:10:35 -0500 (EST)
Received: from efra05-home.Germany.Sun.COM ([129.157.43.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA26364;
	Thu, 11 Jan 2001 02:10:31 -0800 (PST)
Received: from vayne (muc-isdn-11 [129.157.164.111])
	by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id LAA07341;
	Thu, 11 Jan 2001 11:10:28 +0100 (MET)
Date: Thu, 11 Jan 2001 11:20:56 +0100 (MET)
From: Erik Guttman <Erik.Guttman@germany.sun.com>
Reply-To: Erik Guttman <Erik.Guttman@germany.sun.com>
Subject: Re: diameter grammar proposal
To: Mark Eklund <meklund@cisco.com>
Cc: Erik Guttman <erik.guttman@Sun.COM>, aaa-wg@merit.edu,
        Randy Bush <randy@psg.com>
In-Reply-To: "Your message with ID" <Pine.GSO.4.21.0101100950070.6033-100000@titans.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.979208456.28041.erikg@sun-ffm.germany>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Mark,

Thanks for your questions, they helped me see where my grammar
proposal was weak.  I attempt to strengthen  it below.  Please
let me know if this answers your question and meets our needs.
 
> 1. I am used to seeing qualifiers after the argument like in
> regular expressions.  For example Host-Name* instead of
> *Host-Name.  This is a personal preference.

The *, ? and + are in the spirit of ABNF (see RFC 2234) rather
than as glob or regular expressions.  They precede the grammar 
element they qualify.

> 2. Why do you need the optional brackets [] when you have the
> '*' and '?' operators.  I.E. what is the difference in
> *[Host-Name] and *Host-Name?

The grammar conventions I proposed were not formally specified.  That
made it confusing, as you point out.  How about the following ABNF for
all diameter message definitions:

   command-def      = command-name "::=" diameter-message

   diameter-name    = ALPHA *(ALPHA / DIGIT / "-")

   command-name     = diameter-name
                      ; The command-name has to be Command name, defined in
                      ; the base or exteneded DIAMETER specifications.

   diameter-message = header  [ *fixed] [ *required] [ *optional] [ *fixed]

   header           = "<DIAMETER-Header:" command-id ">"

   fixed            = [qual] "<" avp-spec ">"

   required         = [qual] "{" avp-spec "}"

   optional         = [qual] "[" avp-name "]"
                      ; The avp-name in the 'optional' rule cannot evaluate 
                      ; to any AVP Name which is included in a fixed or 
                      ; required rule.              

   qual             = [min] "*" [max]
                      ; Rather than the confusing '?', '+' and '*' 
                      ; use ABNF conventions, RFC 2234 section 3.6.
                      ;  
                      ; NOTE:  "[" and "]" have a different meaning than
                      ; in ABNF (see the optional rule, above).  These 
                      ; braces cannot be used to express an optional fixed
                      ; rules (such as an optional ICV at the end.)  To do 
                      ; this, the convention is '0*1fixed'.

   min              = 1*DIGIT
                      ; The minimum number of times the element may be
                      ; present.

   max              = 1*DIGIT
                      ; The maximum number of times the element may be
                      ; present.

   avp-spec         = diameter-name
                      ; The avp-spec has to be an AVP Name, defined in the 
                      ; base or extended DIAMETER specifications.

   avp-name         = avp-spec | "AVP"
                      ; The string "AVP" stands for *any* arbitrary AVP Name.

This is more restricted than the grammar I described (but did not specify)
in my previous email.  

  (1) You can only put fixed rules at the beginning or end of the message.  
      This limits the possible command grammars you can produce, but I 
      think this is OK.  

  (2) You can only specify one AVP per fixed, required or optional rule, 
      where I indicated you could have any number AVPs in them.  This 
      will make the grammar specifications more verbose.  

  (3) Since you only have one AVP per rule, you only need the 'qual' 
      outside the braces, which eliminates the ambiguity of my initial
      proposal (where you could ask "Where do you put the qual?  What 
      is the meaning of putting it one place instead of the other?  
      What does it mean if you put it in both places? etc.)

The revised 'example' would look like:

     Example-Command ::= <DIAMETER-Header: 9999999>
                         { User-Name }
                        *{ Host-Name }
                        *[ AVP ]
                        0*1< Integrity-Check-Vector >

   The command defined by the preceding grammar MUST begin with a
   DIAMETER header, with the command code Id set to 9999999.  There
   follows a User-Name AVP, zero or more Host-Name AVPs and zero or
   more arbitrary other AVPs (but not User-Name, Host-Name or 
   Integrity-Check-Vector AVPs).  The REQUIRED and OPTIONAL AVPs
   can be permuted into any order, provided that none of them come 
   before the Header or after the Integrity-Check Vector.

> 3. Do you plan to define Grouped-AVP in the specifications?

No - Grouped-AVP is going away, to be replaced by a Grouped value.
Other email on this was sent to the list with the subject

   "data type modifications to DIAMETER"

Erik


._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
E r i k   G u t t m a n         SHORT msgs: 01728655497@d2-message.de
Sr Staff Engineer, Sun Microsystems       Email: erik.guttman@sun.com
Eichhoelzelstr. 7, 74915 Waibstadt Germany    Phone: +49 172 865 5497





From owner-aaa-bof@merit.edu  Thu Jan 11 05:11:23 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28166
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 05:11:23 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id C62405DE49; Thu, 11 Jan 2001 05:10:41 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 95D485DE4A; Thu, 11 Jan 2001 05:10:41 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id BA4005DE49
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 05:10:37 -0500 (EST)
Received: from efra05-home.Germany.Sun.COM ([129.157.43.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA26382;
	Thu, 11 Jan 2001 02:10:35 -0800 (PST)
Received: from vayne (muc-isdn-11 [129.157.164.111])
	by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id LAA07751;
	Thu, 11 Jan 2001 11:10:32 +0100 (MET)
Date: Thu, 11 Jan 2001 11:20:59 +0100 (MET)
From: Erik Guttman <Erik.Guttman@germany.sun.com>
Reply-To: Erik Guttman <Erik.Guttman@germany.sun.com>
Subject: RE: diameter grammar proposal
To: Mark Jones <mjones@bridgewatersystems.com>
Cc: Erik Guttman <erik.guttman@Sun.COM>, aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <008a01c07b37$f6836d80$2096a8c0@bridgewatersys.com>
Message-ID: <Roam.SIMC.2.0.6.979208459.8817.erikg@sun-ffm.germany>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Mark,
 
> Aren't the {} and [] brackets redundant given the 'qual' token definitions?
> 
> i.e.
> '*'  = Zero or more instances MAY be present in the packet = OPTIONAL AVP
> '+'  = At least one instance MUST be present in the packet = MANDATORY AVP
> '?'  = Zero or one instances MAY be present in the packet  = OPTIONAL AVP
>    omitted = Exactly one instance MUST be present in the packet = MANDATORY
> AVP

First - I suggest we get rid of the '+' and '?' qualifiers - they only
confuse the issue.  I suggest a grammar without them in a separate message
sent to the list.

Regarding the use of {} and [] for required and optional definitions:

It is important to distinguish between AVPs required by a command and
those which are optional.  For those that are required, we want to say
how many have to be there.  For those that are optional, we want to leave
things open. 

BUT we have to be sure that by leaving things open we don't allow the 
'optional' rules to collide with the 'required' rules.  Say you
MUST have one and only one 'Foo-AVP' in command X, and there is an
option rule, for sticking in any arbitrary AVP.   You could evaluate
that rule to allow N additional 'Foo-AVP's in the command X message.

That is why I want to separate optional and required AVPs in the 
message specifications.

This does NOT directly relate to the use of the term 'Mandatory' in 
DIAMETER.  Mandatory means the 'M' bit is set - which has consequences
if the receiver of a message doesn't have the ability to interpret the
AVP with the 'M' bit set.  This discussion has been pursued in other
threads.

Erik

._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
E r i k   G u t t m a n         SHORT msgs: 01728655497@d2-message.de
Sr Staff Engineer, Sun Microsystems       Email: erik.guttman@sun.com
Eichhoelzelstr. 7, 74915 Waibstadt Germany    Phone: +49 172 865 5497





From owner-aaa-bof@merit.edu  Thu Jan 11 09:19:47 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01620
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 09:19:47 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id E998E5DDE3; Thu, 11 Jan 2001 09:19:11 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id CF38C5DDB7; Thu, 11 Jan 2001 09:19:11 -0500 (EST)
Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44])
	by segue.merit.edu (Postfix) with ESMTP id 2A2705DD90
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 09:19:10 -0500 (EST)
Received: (from barney@localhost)
	by mx.databus.com (8.11.1/8.11.1) id f0BEJ3p79067;
	Thu, 11 Jan 2001 09:19:03 -0500 (EST)
	(envelope-from barney)
Date: Thu, 11 Jan 2001 09:19:03 -0500
From: Barney Wolff <barney@databus.com>
To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Cc: aaa-wg@merit.edu, diameter@diameter.org
Subject: Re: The Identifier field
Message-ID: <20010111091903.A78837@mx.databus.com>
References: <Roam.SIMC.2.0.6.979173823.19029.pcalhoun@nasnfs>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Roam.SIMC.2.0.6.979173823.19029.pcalhoun@nasnfs>; from Pat.Calhoun@Eng.Sun.COM on Wed, Jan 10, 2001 at 04:43:43PM -0800
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Pat, in RADIUS the id comes back to the originator of a request,
and whether it's modified between proxies is not visible to the
requester.  Why would you want to impose further requirements
above that?  To be sure, a stateless proxy would have to keep
the id unchanged, because it won't notice when the response
comes back, but a stateful proxy will, and can therefore obey
the requirement while still generating a useful id of its own.

You can argue that Proxy-State provides the same opportunity
for fast lookup, but the AVP is not in a fixed position, while
the id is part of the header.

The justification of the field is that it allows the receiver of
a response to do an efficient lookup of its request state.  That
motive stays the same for DIAMETER, and helps proxies as well as
NAS's - but only if the proxy can set the id.  I see no benefit
to disallowing that.  There's already an unmodifiable AVP for
session-id, and we don't need two.

Barney

On Wed, Jan 10, 2001 at 04:43:43PM -0800, Pat Calhoun wrote:
> [ed: I hate this cross-posting, but it seems necessary :(]
> 
> Tony brought up a question some time ago as to the usefulness of the
> Identifier field. I believe that no justification was provided at the time for
> the existence of the field. In the process of editing the base protocol, it
> came to me the reason why such a field may be required.
> 
> Assume for a moment that we are a NAS, and that two authorization messages are
> sent for the same user (let's assume for the moment that these are for
> different services). When either of the responses are received, how would the
> NAS know to match request and the response. The obvious answer is to require
> that the NAS walk through the whole message, looking for clues (e.g. service
> type). This is rather cumbersome.
> 
> The Identifier field DOES provide such a hint. However, we need to make sure
> that the Identifier field IS NOT modified in transit towards the home server
> (as it is done in RADIUS), because there really is no need to do so, and it
> does complicate the protocol. 
> 
> So I propose keeping the Identifier field, but adding text that it is ONLY of
> use to the initiator of a request to match up the response.
> 
> Does this make sense?
> 
> PatC
> 
> 



From owner-aaa-bof@merit.edu  Thu Jan 11 10:23:26 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03445
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 10:23:26 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id DDFEB5DE28; Thu, 11 Jan 2001 10:23:10 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id CAD075DE41; Thu, 11 Jan 2001 10:23:10 -0500 (EST)
Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9])
	by segue.merit.edu (Postfix) with ESMTP id 4BCE95DE28
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 10:23:09 -0500 (EST)
Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2])
	by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id LAA13411;
	Thu, 11 Jan 2001 11:18:59 -0500
Received: from mjones (mjones.bridgewatersys.com [192.168.150.32])
	by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id KAA10527;
	Thu, 11 Jan 2001 10:23:28 -0500 (EST)
From: "Mark Jones" <mjones@bridgewatersystems.com>
To: "Erik Guttman" <Erik.Guttman@germany.sun.com>
Cc: <aaa-wg@merit.edu>
Subject: RE: diameter grammar proposal
Date: Thu, 11 Jan 2001 10:30:08 -0500
Message-ID: <00ca01c07be3$60ffe6b0$2096a8c0@bridgewatersys.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Roam.SIMC.2.0.6.979208459.8817.erikg@sun-ffm.germany>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Erik,

> BUT we have to be sure that by leaving things open we don't allow the
> 'optional' rules to collide with the 'required' rules.

Where 'optional' rules are those rules which refer to optional AVPs. The
rules themselves are NOT optional, correct?

> Say you
> MUST have one and only one 'Foo-AVP' in command X, and there is an
> option rule, for sticking in any arbitrary AVP.   You could evaluate
> that rule to allow N additional 'Foo-AVP's in the command X message.
>

I see. You are concerned about conflicting rules. I am still not convinced
that ambiguity exists here. I had assumed that all rules MUST be satisfied
when evaluating whether a packet is valid. From your example, adding more
Foo-AVPs breaks the first rule and therefore would be illegal.

> This does NOT directly relate to the use of the term 'Mandatory' in
> DIAMETER.  Mandatory means the 'M' bit is set - which has consequences
> if the receiver of a message doesn't have the ability to interpret the
> AVP with the 'M' bit set.  This discussion has been pursued in other
> threads.
>

Agreed. Lets never talk of it again :)

Regards,
       Mark




From owner-aaa-bof@merit.edu  Thu Jan 11 10:29:10 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03769
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 10:29:09 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 1D55B5DE3F; Thu, 11 Jan 2001 10:28:52 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 0BABD5DE39; Thu, 11 Jan 2001 10:28:52 -0500 (EST)
Received: from cisco.com (titans.cisco.com [161.44.216.10])
	by segue.merit.edu (Postfix) with ESMTP id B1F1B5DDB7
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 10:28:49 -0500 (EST)
Received: from titans.cisco.com (titans.cisco.com [161.44.216.10])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA15034;
	Thu, 11 Jan 2001 10:28:11 -0500 (EST)
Date: Thu, 11 Jan 2001 10:28:11 -0500 (EST)
From: Mark Eklund <meklund@cisco.com>
To: Erik Guttman <Erik.Guttman@germany.sun.com>
Cc: Erik Guttman <erik.guttman@Sun.COM>, aaa-wg@merit.edu,
        Randy Bush <randy@psg.com>
Subject: Re: diameter grammar proposal
In-Reply-To: <Roam.SIMC.2.0.6.979208456.28041.erikg@sun-ffm.germany>
Message-ID: <Pine.GSO.4.21.0101111023190.14794-100000@titans.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Erik, 

Thanks, that answers my earlier questions.  

Also, is there a need to support Command Flags like E, I, and R
in this specification?

-mark
 
On Thu, 11 Jan 2001, Erik Guttman wrote:

> Mark,
> 
> Thanks for your questions, they helped me see where my grammar
> proposal was weak.  I attempt to strengthen  it below.  Please
> let me know if this answers your question and meets our needs.
>  
> > 1. I am used to seeing qualifiers after the argument like in
> > regular expressions.  For example Host-Name* instead of
> > *Host-Name.  This is a personal preference.
> 
> The *, ? and + are in the spirit of ABNF (see RFC 2234) rather
> than as glob or regular expressions.  They precede the grammar 
> element they qualify.
> 
> > 2. Why do you need the optional brackets [] when you have the
> > '*' and '?' operators.  I.E. what is the difference in
> > *[Host-Name] and *Host-Name?
> 
> The grammar conventions I proposed were not formally specified.  That
> made it confusing, as you point out.  How about the following ABNF for
> all diameter message definitions:
> 
>    command-def      = command-name "::=" diameter-message
> 
>    diameter-name    = ALPHA *(ALPHA / DIGIT / "-")
> 
>    command-name     = diameter-name
>                       ; The command-name has to be Command name, defined in
>                       ; the base or exteneded DIAMETER specifications.
> 
>    diameter-message = header  [ *fixed] [ *required] [ *optional] [ *fixed]
> 
>    header           = "<DIAMETER-Header:" command-id ">"
> 
>    fixed            = [qual] "<" avp-spec ">"
> 
>    required         = [qual] "{" avp-spec "}"
> 
>    optional         = [qual] "[" avp-name "]"
>                       ; The avp-name in the 'optional' rule cannot evaluate 
>                       ; to any AVP Name which is included in a fixed or 
>                       ; required rule.              
> 
>    qual             = [min] "*" [max]
>                       ; Rather than the confusing '?', '+' and '*' 
>                       ; use ABNF conventions, RFC 2234 section 3.6.
>                       ;  
>                       ; NOTE:  "[" and "]" have a different meaning than
>                       ; in ABNF (see the optional rule, above).  These 
>                       ; braces cannot be used to express an optional fixed
>                       ; rules (such as an optional ICV at the end.)  To do 
>                       ; this, the convention is '0*1fixed'.
> 
>    min              = 1*DIGIT
>                       ; The minimum number of times the element may be
>                       ; present.
> 
>    max              = 1*DIGIT
>                       ; The maximum number of times the element may be
>                       ; present.
> 
>    avp-spec         = diameter-name
>                       ; The avp-spec has to be an AVP Name, defined in the 
>                       ; base or extended DIAMETER specifications.
> 
>    avp-name         = avp-spec | "AVP"
>                       ; The string "AVP" stands for *any* arbitrary AVP Name.
> 
> This is more restricted than the grammar I described (but did not specify)
> in my previous email.  
> 
>   (1) You can only put fixed rules at the beginning or end of the message.  
>       This limits the possible command grammars you can produce, but I 
>       think this is OK.  
> 
>   (2) You can only specify one AVP per fixed, required or optional rule, 
>       where I indicated you could have any number AVPs in them.  This 
>       will make the grammar specifications more verbose.  
> 
>   (3) Since you only have one AVP per rule, you only need the 'qual' 
>       outside the braces, which eliminates the ambiguity of my initial
>       proposal (where you could ask "Where do you put the qual?  What 
>       is the meaning of putting it one place instead of the other?  
>       What does it mean if you put it in both places? etc.)
> 
> The revised 'example' would look like:
> 
>      Example-Command ::= <DIAMETER-Header: 9999999>
>                          { User-Name }
>                         *{ Host-Name }
>                         *[ AVP ]
>                         0*1< Integrity-Check-Vector >
> 
>    The command defined by the preceding grammar MUST begin with a
>    DIAMETER header, with the command code Id set to 9999999.  There
>    follows a User-Name AVP, zero or more Host-Name AVPs and zero or
>    more arbitrary other AVPs (but not User-Name, Host-Name or 
>    Integrity-Check-Vector AVPs).  The REQUIRED and OPTIONAL AVPs
>    can be permuted into any order, provided that none of them come 
>    before the Header or after the Integrity-Check Vector.
> 
> > 3. Do you plan to define Grouped-AVP in the specifications?
> 
> No - Grouped-AVP is going away, to be replaced by a Grouped value.
> Other email on this was sent to the list with the subject
> 
>    "data type modifications to DIAMETER"
> 
> Erik
> 
> 
> ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
> E r i k   G u t t m a n         SHORT msgs: 01728655497@d2-message.de
> Sr Staff Engineer, Sun Microsystems       Email: erik.guttman@sun.com
> Eichhoelzelstr. 7, 74915 Waibstadt Germany    Phone: +49 172 865 5497
> 
> 
> 






From owner-aaa-bof@merit.edu  Thu Jan 11 11:28:35 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06717
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 11:28:35 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 093715DE4A; Thu, 11 Jan 2001 11:28:04 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id E8CAC5DE41; Thu, 11 Jan 2001 11:28:03 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id A9A655DE39
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 11:28:02 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00196;
	Thu, 11 Jan 2001 08:28:00 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA03155;
	Thu, 11 Jan 2001 08:27:57 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA19473;
	Thu, 11 Jan 2001 07:01:10 -0800 (PST)
Date: Thu, 11 Jan 2001 06:57:31 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Redirect 
To: diameter@diameter.org, aaa-wg@merit.edu
Cc: Pat.Calhoun@eng.sun.com
Message-ID: <Roam.SIMC.2.0.6.979225051.2780.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

All,

The current base protocol specification states that a redirect server returns
a response to the requestor with the error code set to redirect. However, some
discussions we have been having recently on this list implies that redirect
and proxy servers may not actually support all extensions, and may only
support the bare minimum required for packets to be forwarded to the home
server.

Therefore, I question how such servers would ever know how to set the command
code field to the correct response. So, if we really need to support the above
case, one of the following needs to be done:

1. Do nothing and require that proxies/redirect servers support extensions
(this is a valid requirement).

2. Make sure that the redirect indication is returned in an MRI
(Message-Reject-Ind) message. However, one does question how request/responses
are matched up properly, and the details of this need to be refined

3. A MUCH more drastic change, and one I am not sure that I like but I am
adding for completeness. No longer distingush request from responses, but
rather make use of the bits in the message header to distinguish whether the
message is a request or a response. So an Access message would have the
request mode (when bits are set), or a response (when the bits indicate a
response). This *seems* clean, but is a huge change for implementations and
the protocol.

I think that the simplest is #2 above, but I am opening up this can of worms
now to get a feel for how people think their proxies will operate.

PatC




From owner-aaa-bof@merit.edu  Thu Jan 11 11:28:47 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06751
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 11:28:46 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 5117E5DE52; Thu, 11 Jan 2001 11:28:08 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 377185DE50; Thu, 11 Jan 2001 11:28:08 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id EFCEA5DE5C
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 11:28:04 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00229;
	Thu, 11 Jan 2001 08:28:02 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA03186;
	Thu, 11 Jan 2001 08:28:01 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id GAA18848;
	Thu, 11 Jan 2001 06:26:15 -0800 (PST)
Date: Thu, 11 Jan 2001 06:22:37 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: The Identifier field
To: Barney Wolff <barney@databus.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>, aaa-wg@merit.edu,
        diameter@diameter.org
In-Reply-To: "Your message with ID" <20010111091903.A78837@mx.databus.com>
Message-ID: <Roam.SIMC.2.0.6.979222957.29962.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Pat, in RADIUS the id comes back to the originator of a request,
> and whether it's modified between proxies is not visible to the
> requester.  Why would you want to impose further requirements
> above that?  To be sure, a stateless proxy would have to keep
> the id unchanged, because it won't notice when the response
> comes back, but a stateful proxy will, and can therefore obey
> the requirement while still generating a useful id of its own.
> 
> You can argue that Proxy-State provides the same opportunity
> for fast lookup, but the AVP is not in a fixed position, while
> the id is part of the header.
> 
> The justification of the field is that it allows the receiver of
> a response to do an efficient lookup of its request state.  That
> motive stays the same for DIAMETER, and helps proxies as well as
> NAS's - but only if the proxy can set the id.  I see no benefit
> to disallowing that.  There's already an unmodifiable AVP for
> session-id, and we don't need two.

ok, I can buy that. However, I am not sure that I want to describe how proxies
make use of the Identifier field, or should I? I believe that I will simply
add text stating that the id is used to match request and replies, and leave
it at that. *However* please keep in mind that the ID only is not really that
useful. Let's consider a NAS that issues an accounting message with the ID set
to 4. As it turns out, it ALSO receives an unsolicited message from a home
server with the ID set to 4. Since it is not the originator of the message,
then it should attempt to ignore the ID field. 

So my text was that the ID, the Session-Id and the command-code are used on
the NAS to match request and replies.

PatC




From owner-aaa-bof@merit.edu  Thu Jan 11 12:28:07 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09526
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 12:28:07 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 881595DFA5; Thu, 11 Jan 2001 12:24:59 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 344BC5DE55; Thu, 11 Jan 2001 12:24:51 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 4C7985DF67
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 12:22:09 -0500 (EST)
Received: from efra05-home.Germany.Sun.COM ([129.157.43.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12497;
	Thu, 11 Jan 2001 09:22:07 -0800 (PST)
Received: from vayne (muc-isdn-8 [129.157.164.108])
	by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id SAA13983;
	Thu, 11 Jan 2001 18:22:05 +0100 (MET)
Date: Thu, 11 Jan 2001 18:32:33 +0100 (MET)
From: Erik Guttman <Erik.Guttman@germany.sun.com>
Reply-To: Erik Guttman <Erik.Guttman@germany.sun.com>
Subject: Re: diameter grammar proposal
To: Mark Eklund <meklund@cisco.com>
Cc: Erik Guttman <erik.guttman@Sun.COM>, aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <Pine.GSO.4.21.0101111023190.14794-100000@titans.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.979234353.21228.erikg@sun-ffm.germany>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Also, is there a need to support Command Flags like E, I, and R
> in this specification?

The grammar specification covers AVPs. The flags are specified 
for all commands (by their type -Ind, -Rqst, -Answer, -Query,
-Reply) and go into the DIAMETER header.

DIAMETER implementations will have to support those flags.  This
is useful for reasons pointed out in draft-ietf-aaa-issues-04.txt
and Pat's point that proxies can benefit from knowing a message
is an Indication, request/query or a reply/answer.

Erik


._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
E r i k   G u t t m a n         SHORT msgs: 01728655497@d2-message.de
Sr Staff Engineer, Sun Microsystems       Email: erik.guttman@sun.com
Eichhoelzelstr. 7, 74915 Waibstadt Germany    Phone: +49 172 865 5497





From owner-aaa-bof@merit.edu  Thu Jan 11 12:30:17 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09636
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 12:30:16 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id D2E985DECF; Thu, 11 Jan 2001 12:27:45 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id B0ED55DEFD; Thu, 11 Jan 2001 12:27:45 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 2FEBF5DECF
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 12:27:44 -0500 (EST)
Received: from efra05-home.Germany.Sun.COM ([129.157.43.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA28497;
	Thu, 11 Jan 2001 09:27:40 -0800 (PST)
Received: from vayne (muc-isdn-8 [129.157.164.108])
	by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id SAA25337;
	Thu, 11 Jan 2001 18:27:38 +0100 (MET)
Date: Thu, 11 Jan 2001 18:38:05 +0100 (MET)
From: Erik Guttman <Erik.Guttman@germany.sun.com>
Reply-To: Erik Guttman <Erik.Guttman@germany.sun.com>
Subject: RE: diameter grammar proposal
To: Mark Jones <mjones@bridgewatersystems.com>
Cc: Erik Guttman <Erik.Guttman@germany.sun.com>, aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <00ca01c07be3$60ffe6b0$2096a8c0@bridgewatersys.com>
Message-ID: <Roam.SIMC.2.0.6.979234685.404.erikg@sun-ffm.germany>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

 
> > BUT we have to be sure that by leaving things open we don't allow the
> > 'optional' rules to collide with the 'required' rules.
> 
> Where 'optional' rules are those rules which refer to optional AVPs. The
> rules themselves are NOT optional, correct?

Right.  I should've said the rules for 'optional AVPs'.

> > Say you
> > MUST have one and only one 'Foo-AVP' in command X, and there is an
> > option rule, for sticking in any arbitrary AVP.   You could evaluate
> > that rule to allow N additional 'Foo-AVP's in the command X message.
> >
> 
> I see. You are concerned about conflicting rules. I am still not convinced
> that ambiguity exists here. I had assumed that all rules MUST be satisfied
> when evaluating whether a packet is valid. From your example, adding more
> Foo-AVPs breaks the first rule and therefore would be illegal.

The current diameter spec (which lists but doesn't constrain AVPs to
include) it is possible to put in WHATEVER, including more Foo-AVPs.  
There is no mechanism to describe as illegal putting in multiple AVPs 
of a given type (or ordering of AVPs in a message).  That is why I am 
proposing a more formal grammar, which still allows constrained, but 
still flexible inclusion of semi-arbitrary AVPs and reordering.

Erik

._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
E r i k   G u t t m a n         SHORT msgs: 01728655497@d2-message.de
Sr Staff Engineer, Sun Microsystems       Email: erik.guttman@sun.com
Eichhoelzelstr. 7, 74915 Waibstadt Germany    Phone: +49 172 865 5497





From owner-aaa-bof@merit.edu  Thu Jan 11 12:54:28 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10761
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 12:54:27 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 1E14A5DE77; Thu, 11 Jan 2001 12:53:47 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 0DB2C5DE74; Thu, 11 Jan 2001 12:53:47 -0500 (EST)
Received: from gate.internaut.com (unknown [64.38.134.108])
	by segue.merit.edu (Postfix) with ESMTP id 90D295DE6C
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 12:53:45 -0500 (EST)
Received: from e1kj2 (kidneybean [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0BHoXR22223
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 09:50:33 -0800
From: "Bernard Aboba" <aboba@internaut.com>
To: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: Security proposals for Interim meeting, Feburary 7, 2001
Date: Thu, 11 Jan 2001 09:53:51 -0800
Message-ID: <OJEJKOMOEAKLMOILFCPJIEEIDOAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

So that we can be prepared for our interim meeting on
February 7, 2001, I'd like to ask for volunteers to
present security proposals. These proposals should be
complete in the sense that they describe everything 
that is required to solve the security issues that 
we face. 

The goal of the exercise will be to convince the
WG that one or more of the proposals are viable in
the real world.

Here's a first cut at what is needed for the various
proposals:

1. CMS. I'd like to see a proposal on how CMS can be
used for both e2e and hop-by-hop security. Also, given
this I'd like to understand whether password hiding is
still necessary, and if so, why. The proposal should
be clear about:
	a. Whether PKI is required or not, and exactly
         what infrastructure is needed (CRL servers, 
         offline/online CAs, etc.)
      b. Efficiency issues (key reuse)
      c. Code size and implementation availability
        (can this be implemented on a NAS?)

2. GSS_API. I'd like to see a proposal describing
the deployment scenarios in more detail. 
Issues to discuss further include:
	a. GSS_API methods that could be supported
         within the 1 round trip framework (is this
         only Kerberos V?)
      b. Proposed mandatory to implement method
      c. Code size and availability
      d. Deployment implications
           1. Kerberos KDC on the Internet? 
           2. IAKERB proxies? 
           3. DNS support for KDC location?
           4. Authorization issues

3. IPSEC. 
Issues to discuss further include:
	a. Can use of ESP with non-null transform 
         eliminate need for password hiding?
      b. Can IKE MM cert policy validate biz relationships or
         is this asking too much?
      c. Security implications of referral
		1. Firewall hole for IPSEC/IKE from any source to
               AAA server
            2. AAA server does packet filtering not firewall
            3. Implications for NAS vulnerabilities
            
	



From owner-aaa-bof@merit.edu  Thu Jan 11 13:05:00 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11322
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 13:04:59 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 97EC95DDD9; Thu, 11 Jan 2001 13:04:43 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 863A45DDB7; Thu, 11 Jan 2001 13:04:43 -0500 (EST)
Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9])
	by segue.merit.edu (Postfix) with ESMTP id 550915DD95
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 13:04:41 -0500 (EST)
Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2])
	by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id OAA14676;
	Thu, 11 Jan 2001 14:00:21 -0500
Received: from mjones (mjones.bridgewatersys.com [192.168.150.32])
	by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id NAA14642;
	Thu, 11 Jan 2001 13:04:50 -0500 (EST)
From: "Mark Jones" <mjones@bridgewatersystems.com>
To: "Pat Calhoun" <Pat.Calhoun@Eng.Sun.COM>
Cc: <aaa-wg@merit.edu>, <diameter@diameter.org>
Subject: RE: [diameter] data type modifications to DIAMETER (Fwd)
Date: Thu, 11 Jan 2001 13:11:30 -0500
Message-ID: <00fc01c07bf9$ebe30210$2096a8c0@bridgewatersys.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Roam.SIMC.2.0.6.979171607.28030.pcalhoun@nasnfs>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat,

> But how would you deal with backward compatibility? This seems especially
> important given that in a roaming network, you never know whether
> the home, or the NAS, support v6.
>

Wouldn't all the RADIUS/DIAMETER servers in the proxy chain will know
whether the NAS itself is IPv6 or IPv4 by virtue of (1) in DIAMETER, the
length of the NAS-IP-Address AVP, or (2) in RADIUS, presence of the
NAS-IP-Address vs NAS-IPv6-Address AVP?

It seem unlikely to me that a RADIUS request received from an IPv6 NAS by a
dual-stack (v4/v6) RADIUS server would then be proxied unmodified to a
legacy IPv4 RADIUS server. Similarly, a RADIUS response received from an
IPv6 RADIUS server would not be returned unmodified to a legacy IPv4 NAS. Do
you think the dual purpose AVP approach would significantly increase the
complexity of the translation being done by a dual-stack RADIUS server?

Whether the host requesting service from the NAS actually supports IPv6 is
another issue since as the RADIUSv6 draft points out:

"Note that a NAS sending a RADIUS Access-Request may not know a-priori
whether the host will be using IPv4, IPv6, or both. For example, within
PPP, NCP occurs after LCP, so that address assignment will not occur
until after RADIUS authentication and authorization has completed.
Therefore it is presumed that the IPv6 attributes described in this
document MAY be sent along with IPv4-related attributes within the same
RADIUS message and that the NAS will decide which attributes to use."

Regards,
       Mark




From owner-aaa-bof@merit.edu  Thu Jan 11 13:05:40 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11362
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 13:05:39 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 6F5225DDDB; Thu, 11 Jan 2001 13:05:24 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 5D3D35DD95; Thu, 11 Jan 2001 13:05:24 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id A30965DDB7
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 13:05:22 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA13451;
	Thu, 11 Jan 2001 10:05:03 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA29920;
	Thu, 11 Jan 2001 10:04:28 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA18825;
	Thu, 11 Jan 2001 10:04:27 -0800 (PST)
Date: Thu, 11 Jan 2001 10:00:48 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: Re: Security proposals for Interim meeting, Feburary 7, 2001
To: Bernard Aboba <aboba@internaut.com>
Cc: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <OJEJKOMOEAKLMOILFCPJIEEIDOAA.aboba@internaut.com>
Message-ID: <Roam.SIMC.2.0.6.979236048.23304.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Bernard,

Should I assume from your e-mail that hop-by-hop is out in the base spec? I
think discounting hop security is a mistake. Should I bring a contribution
detailing this method?

PatC
> So that we can be prepared for our interim meeting on
> February 7, 2001, I'd like to ask for volunteers to
> present security proposals. These proposals should be
> complete in the sense that they describe everything 
> that is required to solve the security issues that 
> we face. 
> 
> The goal of the exercise will be to convince the
> WG that one or more of the proposals are viable in
> the real world.
> 
> Here's a first cut at what is needed for the various
> proposals:
> 
> 1. CMS. I'd like to see a proposal on how CMS can be
> used for both e2e and hop-by-hop security. Also, given
> this I'd like to understand whether password hiding is
> still necessary, and if so, why. The proposal should
> be clear about:
> 	a. Whether PKI is required or not, and exactly
>          what infrastructure is needed (CRL servers, 
>          offline/online CAs, etc.)
>       b. Efficiency issues (key reuse)
>       c. Code size and implementation availability
>         (can this be implemented on a NAS?)
> 
> 2. GSS_API. I'd like to see a proposal describing
> the deployment scenarios in more detail. 
> Issues to discuss further include:
> 	a. GSS_API methods that could be supported
>          within the 1 round trip framework (is this
>          only Kerberos V?)
>       b. Proposed mandatory to implement method
>       c. Code size and availability
>       d. Deployment implications
>            1. Kerberos KDC on the Internet? 
>            2. IAKERB proxies? 
>            3. DNS support for KDC location?
>            4. Authorization issues
> 
> 3. IPSEC. 
> Issues to discuss further include:
> 	a. Can use of ESP with non-null transform 
>          eliminate need for password hiding?
>       b. Can IKE MM cert policy validate biz relationships or
>          is this asking too much?
>       c. Security implications of referral
> 		1. Firewall hole for IPSEC/IKE from any source to
>                AAA server
>             2. AAA server does packet filtering not firewall
>             3. Implications for NAS vulnerabilities
>             
> 	
> 





From owner-aaa-bof@merit.edu  Thu Jan 11 13:12:24 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11562
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 13:12:24 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 51EF05DE39; Thu, 11 Jan 2001 13:12:06 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 409915DDB7; Thu, 11 Jan 2001 13:12:06 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id F12FA5DD95
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 13:12:04 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA17342;
	Thu, 11 Jan 2001 10:12:01 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA02712;
	Thu, 11 Jan 2001 10:12:00 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA29082;
	Thu, 11 Jan 2001 10:11:59 -0800 (PST)
Date: Thu, 11 Jan 2001 10:08:22 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: RE: [diameter] data type modifications to DIAMETER (Fwd)
To: Mark Jones <mjones@bridgewatersystems.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>, aaa-wg@merit.edu,
        diameter@diameter.org
In-Reply-To: "Your message with ID" <00fc01c07bf9$ebe30210$2096a8c0@bridgewatersys.com>
Message-ID: <Roam.SIMC.2.0.6.979236502.24911.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


> Whether the host requesting service from the NAS actually supports IPv6 is
> another issue since as the RADIUSv6 draft points out:
> 
> "Note that a NAS sending a RADIUS Access-Request may not know a-priori
> whether the host will be using IPv4, IPv6, or both. For example, within
> PPP, NCP occurs after LCP, so that address assignment will not occur
> until after RADIUS authentication and authorization has completed.
> Therefore it is presumed that the IPv6 attributes described in this
> document MAY be sent along with IPv4-related attributes within the same
> RADIUS message and that the NAS will decide which attributes to use."

Right, but chances of getting *something* back from the home server are quite
high if two attributes are added, one for each address family, as opposed to
inserting an IPv6 in an attribute that the home server expected to be only
32bit in length. Chances it would drop the request in this case, hence
increasing the difficulty in troubleshooting.

PatC




From owner-aaa-bof@merit.edu  Thu Jan 11 13:18:52 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11679
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 13:18:52 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 8DA815DE41; Thu, 11 Jan 2001 13:15:18 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 78D685DDB7; Thu, 11 Jan 2001 13:15:18 -0500 (EST)
Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44])
	by segue.merit.edu (Postfix) with ESMTP id B47BD5DD95
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 13:15:16 -0500 (EST)
Received: (from barney@localhost)
	by mx.databus.com (8.11.1/8.11.1) id f0BIEDY79894;
	Thu, 11 Jan 2001 13:14:13 -0500 (EST)
	(envelope-from barney)
Date: Thu, 11 Jan 2001 13:14:13 -0500
From: Barney Wolff <barney@databus.com>
To: Bernard Aboba <aboba@internaut.com>
Cc: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: Re: Security proposals for Interim meeting, Feburary 7, 2001
Message-ID: <20010111131413.B79807@mx.databus.com>
References: <OJEJKOMOEAKLMOILFCPJIEEIDOAA.aboba@internaut.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <OJEJKOMOEAKLMOILFCPJIEEIDOAA.aboba@internaut.com>; from aboba@internaut.com on Thu, Jan 11, 2001 at 09:53:51AM -0800
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

It may have been pointed out already, but referral imho does
not imply that the target is the ultimate server that must
itself contain the sensitive user database.  The target
will be whatever the home domain says is its public face -
which if the administrators have any sense, will be a proxy.

Even if you attempt to mandate true "end-ness" such that the
home server is not a proxy, how could anybody outside the
home domain detect a violation?  We would be foolish to
attempt to legislate against things that cannot be detected
or forcibly suppressed.

A proxy makes a much better AAA firewall than any general-purpose
firewall could ever hope to be.

Re IKE-from-anywhere, how does a roaming VPN setup work, if not that?
I too wish that IKE were less DoSable, though.

Barney

On Thu, Jan 11, 2001 at 09:53:51AM -0800, Bernard Aboba wrote:
 ...
> 3. IPSEC. 
>       c. Security implications of referral
> 		1. Firewall hole for IPSEC/IKE from any source to
>                AAA server
>             2. AAA server does packet filtering not firewall



From owner-aaa-bof@merit.edu  Thu Jan 11 13:29:42 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11825
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 13:29:42 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 6596F5DE56; Thu, 11 Jan 2001 13:29:24 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 548C05DE50; Thu, 11 Jan 2001 13:29:24 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 46C105DDB7
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 13:29:23 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24194;
	Thu, 11 Jan 2001 10:29:19 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA07355;
	Thu, 11 Jan 2001 10:29:05 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA04559;
	Thu, 11 Jan 2001 10:29:04 -0800 (PST)
Date: Thu, 11 Jan 2001 10:25:27 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: Preview of new DIAMETER base protocol
To: diameter@diameter.org, aaa-wg@merit.edu
Message-ID: <Roam.SIMC.2.0.6.979237527.27836.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

All,

I am making a preview of the next base protocol available at www.diameter.org.
This version has not been sent to the secretariat for publication, and is
Identified as Alpha 1. 

Given the number of changes, I though it would be worthwhile getting some
review prior to sending it in as a WG work item. It includes:

- Changes from the solutions I-D
- Lots of additional changes throughout the document as a result of the
changes. - Fix to the state machine
- etc, etc.

It does NOT include:
- New ABNF grammar (I thought more comments and careful review of Erik's
proposal 
  would be best).
- AES security (the current text still includes the MD5 style hiding. I have 
  asked for help with AES, and expect to have something soon).

The document can be found at
http://www.diameter.org/draft-calhoun-diameter-18.txt, while the diffs
(against version 17) are at http://www.diameter.org/diffs-in-18.txt.

Although I have reviewed the spec, it is possible that some inconsistencies
still exist. So any feedback would be most appreciated.

Thanks,

PatC




From owner-aaa-bof@merit.edu  Thu Jan 11 13:33:56 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11905
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 13:33:56 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 1B1F15DE83; Thu, 11 Jan 2001 13:33:22 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id F28715DE8D; Thu, 11 Jan 2001 13:33:21 -0500 (EST)
Received: from smtp1.kolumbus.fi (smtp1.kolumbus.fi [193.229.0.36])
	by segue.merit.edu (Postfix) with ESMTP id 60DED5DE83
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 13:33:20 -0500 (EST)
Received: from jariws1 (ab16d3hel.dial.kolumbus.fi [212.54.18.16])
	by smtp1.kolumbus.fi (8.9.0/8.9.0) with SMTP id UAA11449;
	Thu, 11 Jan 2001 20:33:01 +0200 (EET)
Message-ID: <00cf01c07bfc$d5ba3820$8a1b6e0a@arenanet.fi>
From: "Jari Arkko" <jari.arkko@kolumbus.fi>
To: "Pat Calhoun" <Pat.Calhoun@eng.sun.com>,
        "Mark Jones" <mjones@bridgewatersystems.com>
Cc: <aaa-wg@merit.edu>, <diameter@diameter.org>
References: <Roam.SIMC.2.0.6.979236502.24911.pcalhoun@nasnfs>
Subject: Re: [diameter] data type modifications to DIAMETER (Fwd)
Date: Thu, 11 Jan 2001 20:32:20 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Pat writes:

> Right, but chances of getting *something* back from the home server are quite
> high if two attributes are added, one for each address family, as opposed to
> inserting an IPv6 in an attribute that the home server expected to be only
> 32bit in length. Chances it would drop the request in this case, hence
> increasing the difficulty in troubleshooting.

Thinking about the major places (e.g. 3g) where DIAMETER could be
deployed in the future, I think it would be even reasonable to *require* IPv6 attribute
support from all DIAMETER nodes. Which would be rather trivial and
different from than supporting IPv6 itself on DIAMETER or the functions
of the NAS.

Jari





From owner-aaa-bof@merit.edu  Thu Jan 11 13:41:40 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12026
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 13:41:40 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 260AD5DDFB; Thu, 11 Jan 2001 13:41:22 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 1466D5DDB7; Thu, 11 Jan 2001 13:41:22 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id F3F1A5DD95
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 13:41:20 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA29798;
	Thu, 11 Jan 2001 10:41:17 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA11022;
	Thu, 11 Jan 2001 10:41:16 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA04902;
	Thu, 11 Jan 2001 10:41:11 -0800 (PST)
Date: Thu, 11 Jan 2001 10:37:33 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: Re: [diameter] data type modifications to DIAMETER (Fwd)
To: Jari Arkko <jari.arkko@kolumbus.fi>
Cc: aaa-wg@merit.edu, diameter@diameter.org,
        Mark Jones <mjones@bridgewatersystems.com>
In-Reply-To: "Your message with ID" <200101111926.f0BJQiL23668@charizard.diameter.org>
Message-ID: <Roam.SIMC.2.0.6.979238253.12862.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Pat writes:
>
>> Right, but chances of getting *something* back from the home server are
quite >> high if two attributes are added, one for each address family, as
opposed to >> inserting an IPv6 in an attribute that the home server expected
to be only >> 32bit in length. Chances it would drop the request in this case,
hence >> increasing the difficulty in troubleshooting.
>
> Thinking about the major places (e.g. 3g) where DIAMETER could be
> deployed in the future, I think it would be even reasonable to *require* IPv6 
> attribute
> support from all DIAMETER nodes. Which would be rather trivial and
> different from than supporting IPv6 itself on DIAMETER or the functions
> of the NAS.

I didn't think that was the original comment (or perhaps I've really
misunderstood this from the beginning). I thought the issue was more regarding
the RADIUS protocol. v4/v6 support is mandatory in the DIAMETER protocol.
Whether a NAS or Server supports either, or both, protocols is irrelevant. All
we care about is ensuring that requests and responses are recognized.

PatC




From owner-aaa-bof@merit.edu  Thu Jan 11 13:52:48 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12321
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 13:52:44 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 5083D5DE50; Thu, 11 Jan 2001 13:52:19 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 406BA5DDB7; Thu, 11 Jan 2001 13:52:19 -0500 (EST)
Received: from smtp1.kolumbus.fi (smtp1.kolumbus.fi [193.229.0.36])
	by segue.merit.edu (Postfix) with ESMTP id 9F5A25DD95
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 13:52:17 -0500 (EST)
Received: from jariws1 (ab16d3hel.dial.kolumbus.fi [212.54.18.16])
	by smtp1.kolumbus.fi (8.9.0/8.9.0) with SMTP id UAA17089;
	Thu, 11 Jan 2001 20:52:12 +0200 (EET)
Message-ID: <00d401c07bff$8403eaa0$8a1b6e0a@arenanet.fi>
From: "Jari Arkko" <jari.arkko@kolumbus.fi>
To: "Pat Calhoun" <Pat.Calhoun@eng.sun.com>, <diameter@diameter.org>,
        <aaa-wg@merit.edu>
References: <Roam.SIMC.2.0.6.979143171.3363.pcalhoun@nasnfs>
Subject: Re: Proposed change to DIAMETER header
Date: Thu, 11 Jan 2001 20:51:32 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


> The method the protocol is currently specified, it requires that an
> implementation walk through each AVP, looking for the ICV AVP in order to
> perform the necessary replay and authentication checks. What this means is
> that there is a significant amount of work required to ensure that the packet
> is in fact authentic. This does not bode well for denial of service attacks.
> 
> So I would like to propose adding the ICV-Offset to the DIAMETER header, as
> shown below:

I don't care that much either way, but I would just note a couple of
things:

  1) The MAC calculation is in any case heavier than any reasonable ICV
       attribute seeking operation, so I don't really know if this buys that
       much.

       Or perhaps you are simplifying the DIAMETER hardware
       ICV engine design for the next SPARC station ;-)

  2) If I would program a server, I would make a separate small
      piece of code to look for the ICV for received packets; don't
      think more than a simple loop is required since the ICV hopefully
      couldn't be inside any AVP groups, and no XML data dictionaries
      need to be consulted either.

 3) If there's an ICV offset in the header, somebody's going to have
     to go and check later that it corresponds to the actual place
    of the attribute. Also, before the ICV is checked we need to
    ensure it falls within the bounds of the message. Unnecessary
    complexity.

[In any case, I'd rather have statically keyed IPsec as a MUST than
the AVP, since that would be useful for encryption as well as integrity,
and would benefit more apps at the same time.  And again, many
DIAMETER uses I see would be in the v6 domain and there IPsec
exists anyway...]

Jari





From owner-aaa-bof@merit.edu  Thu Jan 11 14:40:34 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13237
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 14:40:34 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 8767C5DEE8; Thu, 11 Jan 2001 14:34:37 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 061B65DE7D; Thu, 11 Jan 2001 14:34:36 -0500 (EST)
Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9])
	by segue.merit.edu (Postfix) with ESMTP id 1EC9D5DE7D
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 14:33:58 -0500 (EST)
Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2])
	by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id PAA15494;
	Thu, 11 Jan 2001 15:29:43 -0500
Received: from mjones (mjones.bridgewatersys.com [192.168.150.32])
	by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id OAA16813;
	Thu, 11 Jan 2001 14:34:12 -0500 (EST)
From: "Mark Jones" <mjones@bridgewatersystems.com>
To: "Pat Calhoun" <Pat.Calhoun@eng.sun.com>
Cc: <aaa-wg@merit.edu>
Subject: RE: [diameter] data type modifications to DIAMETER (Fwd)
Date: Thu, 11 Jan 2001 14:40:52 -0500
Message-ID: <00ff01c07c06$68110dd0$2096a8c0@bridgewatersys.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Roam.SIMC.2.0.6.979236502.24911.pcalhoun@nasnfs>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat,

[diameter@diameter.org removed from CC list. Thread concerns RADIUSv6.]

>
> Right, but chances of getting *something* back from the home
> server are quite
> high if two attributes are added, one for each address family, as
> opposed to
> inserting an IPv6 in an attribute that the home server expected to be only
> 32bit in length. Chances it would drop the request in this case, hence
> increasing the difficulty in troubleshooting.
>

Yes, I understand the potential problem if a packet containing an IPv6
address AVP arrives at an IPv4 RADIUS server:

1) Using two different AVPs, one for each address family

An IPv6 NAS sends an Access-Request containing Foo-IP-Address AVP and
Foo-IPv6-Address AVP to the first hop dual-stack RADIUS server. This RADIUS
server proxies the request unmodified onto an IPv4 RADIUS server. The IPv4
RADIUS server ignores Foo-IPv6-Address since it has an unknown Type but
otherwise processes the request normally.

2) Using two instances of the same AVP, one for each address family

An IPv6 NAS sends an Access-Request containing a 4-byte (IPv4)
Foo-IP-Address AVP and an 8-byte (IPv6) Foo-IP-Address AVP to the first hop
dual-stack RADIUS server. This RADIUS server proxies the request unmodified
onto an IPv4 RADIUS server. The IPv4 RADIUS server drops the request on
encountering an 8-byte Foo-IP-Address since it expected a 4-byte IPv4
address.

Is this the problem you are refering to?

Alternatively, the dual-stack RADIUS server filters out the IPv6 AVPs before
sending on the request to the IPv4 RADIUS server. In my example (2) above,
the dual-stack RADIUS server removes the 8-byte Foo-IP-Address AVP before
forwarding the request. The IPv4 RADIUS server just sees the 4-byte (IPv4)
Foo-IP-Address AVP and processes the request normally.

Regards,
       Mark




From owner-aaa-bof@merit.edu  Thu Jan 11 15:06:02 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13660
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 15:06:01 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id A56295DEF9; Thu, 11 Jan 2001 15:04:59 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 0E16C5DD95; Thu, 11 Jan 2001 15:04:33 -0500 (EST)
Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110])
	by segue.merit.edu (Postfix) with ESMTP id 627205E012
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 14:59:15 -0500 (EST)
Received: from Interlinknetworks.com (unknown [198.108.5.3])
	by aaa.interlinknetworks.com (Postfix) with ESMTP
	id 9827573; Thu, 11 Jan 2001 14:59:22 -0500 (EST)
Message-ID: <3A5E10AF.B687C688@Interlinknetworks.com>
Date: Thu, 11 Jan 2001 14:59:43 -0500
From: David Spence <DSpence@Interlinknetworks.com>
Organization: Interlink Networks, Inc.
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Cc: aaa-wg@merit.edu, diameter@diameter.org
Subject: Re: Capabilities Negotiation and proxies
References: <Roam.SIMC.2.0.6.979174568.27364.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Suppose an AAA server acts as home server for some realms and proxy for
others.  Then what does it advertise?  (Assume that as home server it does
not support all extensions, but as a routing proxy it is willing to proxy
all extensions.)

Pat Calhoun wrote:
> 
> All,
> 
> As discussed a few days ago, a proxy MAY wish to proxy ANY type of message,
> regardless of the extension. Therefore, the current text in the base protocol
> does not allow this behavior since it would require that proxies advertise ALL
> possible extensions.
> 
> Therefore, I am proposing adding the last paragraph to section 2.5.3.
> Furthermore, I believe that ALL messages MUST include the extension ID of the
> particular message. The reason being that a proxy would need to identify a
> server in the home domain that can handle the message, but it may not recognize
> the command.
> 
> Comments? Objections? Proposed Text?
> 
> PatC
> 
> 2.5.3  Extension-Id AVP
> 
>    The Extension-Id AVP (AVP Code 258) is of type Unsigned32 and is used
>    in order to identify a specific DIAMETER extension. This AVP is used
>    in the Device-Reboot-Ind message in order to inform the peer what
>    extensions are locally supported. The Extension-Id MUST also be present
>    in all messages that are defined in a separate DIAMETER specification
>    and have an Extension ID assigned.
> 
>    Each DIAMETER extension draft MUST have an IANA assigned extension
>    Idenfier (see section 8.3). The base protocol does not require an
>    Extension-Id since its support is mandatory.
> 
>    There MAY be more than one Extension-Id AVP within a DIAMETER
>    Device-Reboot-Ind message. The following values are recognized:
> 
>       NASREQ              1 [7]
>       Strong Security     2 [11]
>       Resource Management 3 [29]
>       Mobile-IP           4 [10]
>       Accounting          5 [15]
> 
>       Furthermore, servers acting as Redirect or Proxy servers (see
>       Section 6.0) MAY wish to advertise support for ALL possible
>       extensions. Such servers are then responsible for finding a
>       downstream server that supports the extension of a particular
>       message. This is done by including the Extension-Id AVP with a
>       value of zero (0).

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



From owner-aaa-bof@merit.edu  Thu Jan 11 15:23:56 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13899
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 15:23:56 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id BB8175DEF5; Thu, 11 Jan 2001 15:23:39 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A8C645DEDF; Thu, 11 Jan 2001 15:23:39 -0500 (EST)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 69CDC5DEDC
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 15:23:38 -0500 (EST)
Received: from gwzpc ([64.104.42.105] (may be forged)) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id MAA03386; Thu, 11 Jan 2001 12:23:00 -0800 (PST)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Pat Calhoun" <Pat.Calhoun@eng.sun.com>,
        "Mark Jones" <mjones@bridgewatersystems.com>
Cc: <aaa-wg@merit.edu>, <diameter@diameter.org>
Subject: RE: [diameter] data type modifications to DIAMETER (Fwd)
Date: Thu, 11 Jan 2001 12:13:03 -0800
Message-ID: <NDBBIHMPILAAGDHPCIOPCEEFDBAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.979171607.28030.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com] writes:

> > Would new RADIUS attributes for IPv6 addresses still be
> required if RADIUSv6
> > were to adopt the dual purpose AVP approach?

Wouldn't this scheme require changes to RADIUS data types?  That can't be
done...

> > If, as suggested by the
> > RADIUSv6 spec, the RADIUS packet contained both IPv4 and IPv6
> AVPs, the NAS
> > can still distinguish the IPv4/IPv6 addresses by their length and so can
> > choose the appropriate instance of the address AVP depending on
> whether its
> > client is IPv4 or IPv6.
> >
> > If there is not a common approach to IPv4/IPv6 address encoding, the
> > DIAMETER-RADIUS gateway must translate, for example, a DIAMETER
> > Login-IP-Host AVP to a RADIUS Login-IP-Host or Login-IPv6-Host
> AVP depending
> > on its length. Not complex. Just tedious.

Such is the life of a gateway :-)

>
> But how would you deal with backward compatibility? This seems especially
> important given that in a roaming network, you never know whether
> the home, or
> the NAS, support v6.
>
> PatC
>
>
>




From owner-aaa-bof@merit.edu  Thu Jan 11 15:44:04 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14237
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 15:44:03 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id B75675DF93; Thu, 11 Jan 2001 15:42:03 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 992045DF92; Thu, 11 Jan 2001 15:42:03 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 4CE6B5DE8A
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 15:42:02 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA13095;
	Thu, 11 Jan 2001 12:42:00 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA16476;
	Thu, 11 Jan 2001 12:41:55 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA12597;
	Thu, 11 Jan 2001 12:41:52 -0800 (PST)
Date: Thu, 11 Jan 2001 12:38:14 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: Capabilities Negotiation and proxies
To: David Spence <DSpence@Interlinknetworks.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>, aaa-wg@merit.edu,
        diameter@diameter.org
In-Reply-To: "Your message with ID" <3A5E10AF.B687C688@Interlinknetworks.com>
Message-ID: <Roam.SIMC.2.0.6.979245494.6737.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Then it would return the error code stating that the extension was not
supported. Furthermore, I sent some text early this week (or was it last
week), that would solve this problem, but it was a major change. It would
require that all home servers advertise their local domains. The proxy could
then use this information to figure out whether the next hop is a proxy, or a
home server for a given domain.

btw, I am NOT attempting to create a routing protocol for NAIs. This is a
one-hop only thing.

Still not really sure that I like this approach either, but I am willing to
listen to suggestions.

PatC




From owner-aaa-bof@merit.edu  Thu Jan 11 15:49:00 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14290
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 15:49:00 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 01D065DE7F; Thu, 11 Jan 2001 15:45:05 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id B81AC5DE8A; Thu, 11 Jan 2001 15:45:03 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 61CB75DE7F
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 15:45:01 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13074;
	Thu, 11 Jan 2001 12:44:58 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA17347;
	Thu, 11 Jan 2001 12:44:57 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA12665;
	Thu, 11 Jan 2001 12:44:56 -0800 (PST)
Date: Thu, 11 Jan 2001 12:41:18 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: RE: [diameter] data type modifications to DIAMETER (Fwd)
To: gwz@cisco.com
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        Mark Jones <mjones@bridgewatersystems.com>, aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <NDBBIHMPILAAGDHPCIOPCEEFDBAA.gwz@cisco.com>
Message-ID: <Roam.SIMC.2.0.6.979245678.28148.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com] writes:
> 
> > > Would new RADIUS attributes for IPv6 addresses still be
> > required if RADIUSv6
> > > were to adopt the dual purpose AVP approach?
> 
> Wouldn't this scheme require changes to RADIUS data types?  That can't be
> done...

That's my point, but Mark is envisioning an environment where proxies strip
out AVPs based on the next hop's capabilities (see previous e-mail). Of
course, this doesn't help too much in environments where a v6 nas talks to a
v4/v6 proxy, to a v4 proxy then to a v4/v6 home server.

PatC




From owner-aaa-bof@merit.edu  Thu Jan 11 16:40:37 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15173
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 16:40:37 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id C6F7C5DDBA; Thu, 11 Jan 2001 16:40:19 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id AE8225DE5D; Thu, 11 Jan 2001 16:40:19 -0500 (EST)
Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44])
	by segue.merit.edu (Postfix) with ESMTP id 5CBF15DDBA
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 16:40:18 -0500 (EST)
Received: (from barney@localhost)
	by mx.databus.com (8.11.1/8.11.1) id f0BLe5U80617;
	Thu, 11 Jan 2001 16:40:05 -0500 (EST)
	(envelope-from barney)
Date: Thu, 11 Jan 2001 16:40:05 -0500
From: Barney Wolff <barney@databus.com>
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: David Spence <DSpence@Interlinknetworks.com>, aaa-wg@merit.edu,
        diameter@diameter.org
Subject: Re: Capabilities Negotiation and proxies
Message-ID: <20010111164005.A80566@mx.databus.com>
References: <3A5E10AF.B687C688@Interlinknetworks.com> <Roam.SIMC.2.0.6.979245494.6737.pcalhoun@nasnfs>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Roam.SIMC.2.0.6.979245494.6737.pcalhoun@nasnfs>; from Pat.Calhoun@eng.sun.com on Thu, Jan 11, 2001 at 12:38:14PM -0800
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Tell us why a requester should know or care whether its "server"
is actually a home server or another proxy.  IMHO, that would
be a really bad thing.

We're running into the downside of session-oriented AAA, when
the underlying situation is independent transactions.  I suggest
we simply ignore it - the AAA requester should be configured for
the server it talks to "most of the time" and just recover in
real time from what should be very rare cases, that a Mandatory
AVP, or even a whole extension, is not understood by some
roamer's home server.

Barney

On Thu, Jan 11, 2001 at 12:38:14PM -0800, Pat Calhoun wrote:
> Then it would return the error code stating that the extension was not
> supported. Furthermore, I sent some text early this week (or was it last
> week), that would solve this problem, but it was a major change. It would
> require that all home servers advertise their local domains. The proxy could
> then use this information to figure out whether the next hop is a proxy, or a
> home server for a given domain.
> 
> btw, I am NOT attempting to create a routing protocol for NAIs. This is a
> one-hop only thing.
> 
> Still not really sure that I like this approach either, but I am willing to
> listen to suggestions.
> 
> PatC
> 
> 



From owner-aaa-bof@merit.edu  Thu Jan 11 17:18:43 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15589
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 17:18:43 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id C42AD5DE6D; Thu, 11 Jan 2001 17:16:23 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id B26615DE66; Thu, 11 Jan 2001 17:16:23 -0500 (EST)
Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110])
	by segue.merit.edu (Postfix) with ESMTP id DDA935DDEF
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 17:16:22 -0500 (EST)
Received: from phoenix (unknown [198.108.5.3])
	by aaa.interlinknetworks.com (Postfix) with SMTP id 559F574
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 17:16:30 -0500 (EST)
From: "Bob Kopacz" <BKopacz@InterlinkNetworks.com>
To: "Aaa-Wg" <aaa-wg@merit.edu>
Subject: DIAMETER Base Protocol (Alpha 1) / 2.5.1  Vendor-Name AVP
Date: Thu, 11 Jan 2001 17:15:57 -0500
Message-ID: <NEBBKEONLKEDJCMHGHPIOEGKCAAA.BKopacz@InterlinkNetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pat,

The DRI contains a Vendor-Name AVP, which the draft says
is so that a Diameter peer might "know which vendor
specific attributes may be sent to the peer".

Since it is the 32-bit vendor number that appears in the
AVP header and in the Diameter header, should the DRI
instead include a Vendor-ID AVP which contains the
vendor's enterprise code?  It seems a vendor ID value
would be more directly useful for the above-mentioned
purpose.

Or if the Vendor-Name AVP is the way to go, should there
be a list of vendor name strings so that they can be
mapped to known vendors, and an indication if this string
is case-sensitive, etc.?

The "DIAMETER Base Protocol (Alpha 1)" document says:

> 2.5.1  Vendor-Name AVP
> 
> The Vendor-Name AVP (AVP Code 266) is of type
> OctetString and is used to inform a DIAMETER peer of the
> Vendor Name of the DIAMETER device. This MAY be used in
> order to know which vendor specific attributes may be
> sent to the peer. It is also envisioned that the
> combination of the Vendor-Name and the Firmware-Revision
> (section 2.5.2) AVPs MAY provide very useful debugging
> information.




From owner-aaa-bof@merit.edu  Thu Jan 11 17:25:18 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15658
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 17:25:18 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id BD37A5DE9E; Thu, 11 Jan 2001 17:21:38 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9AA855DEA5; Thu, 11 Jan 2001 17:21:38 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 21E095DE93
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 17:21:37 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA16208;
	Thu, 11 Jan 2001 14:21:35 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA04168;
	Thu, 11 Jan 2001 14:21:35 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA28320;
	Thu, 11 Jan 2001 14:21:34 -0800 (PST)
Date: Thu, 11 Jan 2001 14:17:55 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: Re: DIAMETER Base Protocol (Alpha 1) / 2.5.1  Vendor-Name AVP
To: Bob Kopacz <BKopacz@InterlinkNetworks.com>
Cc: Aaa-Wg <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <NEBBKEONLKEDJCMHGHPIOEGKCAAA.BKopacz@InterlinkNetworks.com>
Message-ID: <Roam.SIMC.2.0.6.979251475.6508.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

I have no idea why a name was chosen over the IANA managed value. I agree that
using the value that one would find in the Vendor-Id field seems much more
reasonable. I think that the name was added for debugging purpose so users
(that have no idea what IANA, much less enterprise numbers) can figure out
what's at the other end.

What do other prefer? Just the ID, or both?

Thanks for the great catch!

PatC
> Hi Pat,
> 
> The DRI contains a Vendor-Name AVP, which the draft says
> is so that a Diameter peer might "know which vendor
> specific attributes may be sent to the peer".
> 
> Since it is the 32-bit vendor number that appears in the
> AVP header and in the Diameter header, should the DRI
> instead include a Vendor-ID AVP which contains the
> vendor's enterprise code?  It seems a vendor ID value
> would be more directly useful for the above-mentioned
> purpose.
> 
> Or if the Vendor-Name AVP is the way to go, should there
> be a list of vendor name strings so that they can be
> mapped to known vendors, and an indication if this string
> is case-sensitive, etc.?
> 
> The "DIAMETER Base Protocol (Alpha 1)" document says:
> 
> > 2.5.1  Vendor-Name AVP
> > 
> > The Vendor-Name AVP (AVP Code 266) is of type
> > OctetString and is used to inform a DIAMETER peer of the
> > Vendor Name of the DIAMETER device. This MAY be used in
> > order to know which vendor specific attributes may be
> > sent to the peer. It is also envisioned that the
> > combination of the Vendor-Name and the Firmware-Revision
> > (section 2.5.2) AVPs MAY provide very useful debugging
> > information.
> 
> 





From owner-aaa-bof@merit.edu  Thu Jan 11 17:28:10 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15686
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 17:28:10 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 9D0A05DE99; Thu, 11 Jan 2001 17:27:53 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 89E6B5DE9A; Thu, 11 Jan 2001 17:27:53 -0500 (EST)
Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110])
	by segue.merit.edu (Postfix) with ESMTP id BAF2B5DE99
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 17:27:52 -0500 (EST)
Received: from phoenix (unknown [198.108.5.3])
	by aaa.interlinknetworks.com (Postfix) with SMTP id 232F575
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 17:28:00 -0500 (EST)
From: "Bob Kopacz" <BKopacz@InterlinkNetworks.com>
To: "Aaa-Wg" <aaa-wg@merit.edu>
Subject: DIAMETER Base Protocol (Alpha 1) / 2.4  State Machine
Date: Thu, 11 Jan 2001 17:27:26 -0500
Message-ID: <NEBBKEONLKEDJCMHGHPIIEGLCAAA.BKopacz@InterlinkNetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

Here's a couple State/Event combinations that are not mentioned
in the "2.4  State Machine" section, as to what to do if you
receive something other than a DRI in response to your DRI.

Case 1:

    State     Event                          Action    New State
    -----     -----                          ------    ---------
    Wait-DRI  Receive MRI (to my DRI*)       ?         ?

    *In this case, I guess you recognize that the MRI is in 
    response to your DRI by matching the Identifier.
    
    Does action depend on whether MRI is in response to
    my DRI, or is some out-of-the-blue MRI?

    I'd guess that, in either case,
    Action = Clean up & New State = Closed.

Case 2:

    State     Event                          Action    New State
    -----     -----                          ------    ---------
    Wait-DRI  Receive message other than     ?         ?
              MRI or DRI.

    I'd guess either Action = Ignore & New State = Wait-DRI, 
    or Action = Clean up & New State = Closed.



From owner-aaa-bof@merit.edu  Thu Jan 11 17:44:07 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15843
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 17:44:07 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 6F5CA5DD8D; Thu, 11 Jan 2001 17:43:50 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 5C94C5DDEF; Thu, 11 Jan 2001 17:43:50 -0500 (EST)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 15AA95DD8D
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 17:43:49 -0500 (EST)
Received: from gwzpc ([10.64.194.1] (may be forged)) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id OAA28550; Thu, 11 Jan 2001 14:37:58 -0800 (PST)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Mark Jones" <mjones@bridgewatersystems.com>,
        "Pat Calhoun" <Pat.Calhoun@eng.sun.com>
Cc: <aaa-wg@merit.edu>
Subject: RE: [diameter] data type modifications to DIAMETER (Fwd)
Date: Thu, 11 Jan 2001 14:28:06 -0800
Message-ID: <NDBBIHMPILAAGDHPCIOPEEEKDBAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <00ff01c07c06$68110dd0$2096a8c0@bridgewatersys.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Mark Jones [mailto:mjones@bridgewatersystems.com] writes:

> Pat,
>
> [diameter@diameter.org removed from CC list. Thread concerns RADIUSv6.]
>
> >
> > Right, but chances of getting *something* back from the home
> > server are quite
> > high if two attributes are added, one for each address family, as
> > opposed to
> > inserting an IPv6 in an attribute that the home server expected
> to be only
> > 32bit in length. Chances it would drop the request in this case, hence
> > increasing the difficulty in troubleshooting.
> >
>
> Yes, I understand the potential problem if a packet containing an IPv6
> address AVP arrives at an IPv4 RADIUS server:
>
> 1) Using two different AVPs, one for each address family
>
> An IPv6 NAS sends an Access-Request containing Foo-IP-Address AVP and
> Foo-IPv6-Address AVP to the first hop dual-stack RADIUS server.

Why does the RADIUS server need to be dual-stack?  We're talking attributes
here...

> This RADIUS
> server proxies the request unmodified onto an IPv4 RADIUS server. The IPv4
> RADIUS server ignores Foo-IPv6-Address since it has an unknown Type but
> otherwise processes the request normally.
>
> 2) Using two instances of the same AVP, one for each address family
>
> An IPv6 NAS sends an Access-Request containing a 4-byte (IPv4)
> Foo-IP-Address AVP and an 8-byte (IPv6) Foo-IP-Address AVP to the
> first hop
> dual-stack RADIUS server.

If the 'Foo'=='NAS' in this case, it is prohibited by RFC 2865.

> This RADIUS server proxies the request
> unmodified
> onto an IPv4 RADIUS server. The IPv4 RADIUS server drops the request on
> encountering an 8-byte Foo-IP-Address since it expected a 4-byte IPv4
> address.
>
> Is this the problem you are refering to?
>
> Alternatively, the dual-stack RADIUS server filters out the IPv6
> AVPs before
> sending on the request to the IPv4 RADIUS server. In my example (2) above,
> the dual-stack RADIUS server removes the 8-byte Foo-IP-Address AVP before
> forwarding the request. The IPv4 RADIUS server just sees the 4-byte (IPv4)
> Foo-IP-Address AVP and processes the request normally.

I don't think that it matters what version of IP the RADIUS server is
running, just what Attributes it supports.  The reason why new Attributes
were defined is that the kind ofthing you are describing is illegal in
RADIUS.

>
> Regards,
>        Mark
>
>
>




From owner-aaa-bof@merit.edu  Thu Jan 11 17:57:54 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16001
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 17:57:54 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id B304D5DE9B; Thu, 11 Jan 2001 17:53:00 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 692DF5DF0B; Thu, 11 Jan 2001 17:53:00 -0500 (EST)
Received: from gate.internaut.com (unknown [64.38.134.108])
	by segue.merit.edu (Postfix) with ESMTP id 57D535DE98
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 17:52:57 -0500 (EST)
Received: from e1kj2 (kidneybean [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0BMngR06251;
	Thu, 11 Jan 2001 14:49:42 -0800
From: "Bernard Aboba" <aboba@internaut.com>
To: "Pat Calhoun" <Pat.Calhoun@Eng.Sun.COM>
Cc: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: RE: Security proposals for Interim meeting, Feburary 7, 2001
Date: Thu, 11 Jan 2001 14:53:02 -0800
Message-ID: <OJEJKOMOEAKLMOILFCPJOEFADOAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Roam.SIMC.2.0.6.979236048.23304.pcalhoun@nasnfs>
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I wouldn't assume that anything is out. We're just asking
people to justify whatever they want to put in :)

Contributions welcome. 

-----Original Message-----
From: Pat Calhoun [mailto:Pat.Calhoun@Eng.Sun.COM]
Sent: Thursday, January 11, 2001 10:01 AM
To: Bernard Aboba
Cc: Aaa-Wg@Merit. Edu
Subject: Re: Security proposals for Interim meeting, Feburary 7, 2001


Bernard,

Should I assume from your e-mail that hop-by-hop is out in the base spec? I
think discounting hop security is a mistake. Should I bring a contribution
detailing this method?

PatC
> So that we can be prepared for our interim meeting on
> February 7, 2001, I'd like to ask for volunteers to
> present security proposals. These proposals should be
> complete in the sense that they describe everything 
> that is required to solve the security issues that 
> we face. 
> 
> The goal of the exercise will be to convince the
> WG that one or more of the proposals are viable in
> the real world.
> 
> Here's a first cut at what is needed for the various
> proposals:
> 
> 1. CMS. I'd like to see a proposal on how CMS can be
> used for both e2e and hop-by-hop security. Also, given
> this I'd like to understand whether password hiding is
> still necessary, and if so, why. The proposal should
> be clear about:
> 	a. Whether PKI is required or not, and exactly
>          what infrastructure is needed (CRL servers, 
>          offline/online CAs, etc.)
>       b. Efficiency issues (key reuse)
>       c. Code size and implementation availability
>         (can this be implemented on a NAS?)
> 
> 2. GSS_API. I'd like to see a proposal describing
> the deployment scenarios in more detail. 
> Issues to discuss further include:
> 	a. GSS_API methods that could be supported
>          within the 1 round trip framework (is this
>          only Kerberos V?)
>       b. Proposed mandatory to implement method
>       c. Code size and availability
>       d. Deployment implications
>            1. Kerberos KDC on the Internet? 
>            2. IAKERB proxies? 
>            3. DNS support for KDC location?
>            4. Authorization issues
> 
> 3. IPSEC. 
> Issues to discuss further include:
> 	a. Can use of ESP with non-null transform 
>          eliminate need for password hiding?
>       b. Can IKE MM cert policy validate biz relationships or
>          is this asking too much?
>       c. Security implications of referral
> 		1. Firewall hole for IPSEC/IKE from any source to
>                AAA server
>             2. AAA server does packet filtering not firewall
>             3. Implications for NAS vulnerabilities
>             
> 	
> 






From owner-aaa-bof@merit.edu  Thu Jan 11 18:03:24 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16098
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 18:03:24 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id E166D5DEBC; Thu, 11 Jan 2001 18:00:25 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 4A3B65DF30; Thu, 11 Jan 2001 18:00:25 -0500 (EST)
Received: from gate.internaut.com (unknown [64.38.134.108])
	by segue.merit.edu (Postfix) with ESMTP id 124295DEA4
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 17:57:24 -0500 (EST)
Received: from e1kj2 (kidneybean [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0BMs9R06465;
	Thu, 11 Jan 2001 14:54:09 -0800
From: "Bernard Aboba" <aboba@internaut.com>
To: "Barney Wolff" <barney@databus.com>
Cc: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: RE: Security proposals for Interim meeting, Feburary 7, 2001
Date: Thu, 11 Jan 2001 14:57:29 -0800
Message-ID: <OJEJKOMOEAKLMOILFCPJCEFBDOAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <20010111131413.B79807@mx.databus.com>
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>Re IKE-from-anywhere, how does a roaming VPN setup work, if not that?
>I too wish that IKE were less DoSable, though.

Indeed, a VPN taking connections from anywhere would indeed work like
this in terms of the firewall filters. However, we don't see that many
people installing servers as VPN termination devices; most seem to use
embedded VPN devices, partly due to security concerns.

Also in the VPN case, you can assume that the users would have certs from
the
enterprise that you're offering access to. In the AAA case, the roaming
associations are the trusted root CAs. That's very tricky to pull off.




From owner-aaa-bof@merit.edu  Thu Jan 11 18:13:16 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16161
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 18:13:15 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id B27775DE7C; Thu, 11 Jan 2001 18:13:00 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A2D7F5DE7B; Thu, 11 Jan 2001 18:13:00 -0500 (EST)
Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9])
	by segue.merit.edu (Postfix) with ESMTP id 64DF45DE60
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 18:12:59 -0500 (EST)
Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2])
	by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id TAA17265;
	Thu, 11 Jan 2001 19:08:50 -0500
Received: from mjones (mjones.bridgewatersys.com [192.168.150.32])
	by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id SAA21049;
	Thu, 11 Jan 2001 18:13:19 -0500 (EST)
From: "Mark Jones" <mjones@bridgewatersystems.com>
To: "Pat Calhoun" <Pat.Calhoun@eng.sun.com>
Cc: <aaa-wg@merit.edu>
Subject: RE: [diameter] data type modifications to DIAMETER (Fwd)
Date: Thu, 11 Jan 2001 18:19:58 -0500
Message-ID: <012901c07c25$03cee9e0$2096a8c0@bridgewatersys.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Roam.SIMC.2.0.6.979245678.28148.pcalhoun@nasnfs>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat,

> Of course, this doesn't help too much in environments where a v6 nas
> talks to a v4/v6 proxy, to a v4 proxy then to a v4/v6 home server.
>

Yes, you're right. The IPv6 AVP filtering definitely fails in this scenario.
I've learned my lesson: Don't try to ease the migration by trying to mess
with the legacy protocol.

Regards,
       Mark




From owner-aaa-bof@merit.edu  Thu Jan 11 18:18:50 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16220
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 18:18:49 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 961675DE66; Thu, 11 Jan 2001 18:15:44 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 8130D5DE71; Thu, 11 Jan 2001 18:15:44 -0500 (EST)
Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9])
	by segue.merit.edu (Postfix) with ESMTP id 639275DE66
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 18:15:43 -0500 (EST)
Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2])
	by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id TAA17279;
	Thu, 11 Jan 2001 19:11:34 -0500
Received: from mjones (mjones.bridgewatersys.com [192.168.150.32])
	by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id SAA21075;
	Thu, 11 Jan 2001 18:16:02 -0500 (EST)
From: "Mark Jones" <mjones@bridgewatersystems.com>
To: <gwz@cisco.com>
Cc: <aaa-wg@merit.edu>
Subject: RE: [diameter] data type modifications to DIAMETER (Fwd)
Date: Thu, 11 Jan 2001 18:22:42 -0500
Message-ID: <012c01c07c25$65840940$2096a8c0@bridgewatersys.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <NDBBIHMPILAAGDHPCIOPEEEKDBAA.gwz@cisco.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Glen,

> Why does the RADIUS server need to be dual-stack?  We're talking
> attributes
> here...
>

I meant that the host on which the RADIUS server was running has both IPv4
and IPv6 connections. This is obviously only relevant if the RADIUS server
is manipulating attributes depending on whether the destination is a v4 or
v6 host. I now understand where this approach fails in a proxy chain
scenario (see my reply to Pat).

Regards,
       Mark




From owner-aaa-bof@merit.edu  Thu Jan 11 18:25:51 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16330
	for <aaa-archive@odin.ietf.org>; Thu, 11 Jan 2001 18:25:50 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 3E86F5E027; Thu, 11 Jan 2001 18:23:49 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 272455E026; Thu, 11 Jan 2001 18:23:49 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id D4D335DEE3
	for <aaa-wg@merit.edu>; Thu, 11 Jan 2001 18:23:47 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02982;
	Thu, 11 Jan 2001 15:23:19 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA20372;
	Thu, 11 Jan 2001 15:23:19 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA00458;
	Thu, 11 Jan 2001 15:23:09 -0800 (PST)
Date: Thu, 11 Jan 2001 15:19:30 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: RE: [diameter] data type modifications to DIAMETER (Fwd)
To: Mark Jones <mjones@bridgewatersystems.com>
Cc: gwz@cisco.com, aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <012c01c07c25$65840940$2096a8c0@bridgewatersys.com>
Message-ID: <Roam.SIMC.2.0.6.979255170.19355.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Glen,
> 
> > Why does the RADIUS server need to be dual-stack?  We're talking
> > attributes
> > here...
> >
> 
> I meant that the host on which the RADIUS server was running has both IPv4
> and IPv6 connections. This is obviously only relevant if the RADIUS server
> is manipulating attributes depending on whether the destination is a v4 or
> v6 host. I now understand where this approach fails in a proxy chain
> scenario (see my reply to Pat).
> 
Glen's question was more to the fact that a RADIUS server doesn't have to be
dual stack (or support both IP protocols in the kernel). It merely has to be
able to support both address families in the server (app layer)
implementation. So your use of dual-stack was a little misleading.

PatC




From owner-aaa-bof@merit.edu  Fri Jan 12 04:22:54 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06456
	for <aaa-archive@odin.ietf.org>; Fri, 12 Jan 2001 04:22:54 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 750045DDB4; Fri, 12 Jan 2001 04:22:25 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 4C7135DDAA; Fri, 12 Jan 2001 04:22:25 -0500 (EST)
Received: from localhost.ipunplugged.com (unknown [195.42.212.161])
	by segue.merit.edu (Postfix) with ESMTP id 5D52A5DDB4
	for <aaa-wg@merit.edu>; Fri, 12 Jan 2001 04:22:23 -0500 (EST)
Received: from fredrikj (c8.local.ipunplugged.com [192.168.4.207])
	by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA24138;
	Fri, 12 Jan 2001 10:23:16 +0100
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Pat Calhoun" <Pat.Calhoun@Eng.Sun.COM>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: RE: Capabilities Negotiation and proxies
Date: Fri, 12 Jan 2001 10:24:46 +0100
Message-ID: <MJEMJBGGCLLDLFFAHLJKKEPHCEAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Roam.SIMC.2.0.6.979174568.27364.pcalhoun@nasnfs>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pat,

If there MUST be an Extension-Id AVP in all messages defined in other
DIAMETER specifications, the the section below:

"There MAY be more than one Extension-Id AVP within a DIAMETER
   Device-Reboot-Ind message. The following values are recognized:"

should be changed to:

"There MAY be more than one Extension-Id AVP within a DIAMETER message. The
following values are recognized:"

Since one can for example use Strong Security together with another
extension in the same message.

B.R.
/Fredrik

>-----Original Message-----
>From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
>Of Pat Calhoun
>Sent: den 11 januari 2001 01:56
>To: aaa-wg@merit.edu; diameter@diameter.org
>Subject: Capabilities Negotiation and proxies
>
>
>All,
>
>As discussed a few days ago, a proxy MAY wish to proxy ANY type of message,
>regardless of the extension. Therefore, the current text in the
>base protocol
>does not allow this behavior since it would require that proxies
>advertise ALL
>possible extensions.
>
>Therefore, I am proposing adding the last paragraph to section 2.5.3.
>Furthermore, I believe that ALL messages MUST include the
>extension ID of the
>particular message. The reason being that a proxy would need to identify a
>server in the home domain that can handle the message, but it may
>not recognize
>the command.
>
>Comments? Objections? Proposed Text?
>
>PatC
>
>2.5.3  Extension-Id AVP
>
>   The Extension-Id AVP (AVP Code 258) is of type Unsigned32 and is used
>   in order to identify a specific DIAMETER extension. This AVP is used
>   in the Device-Reboot-Ind message in order to inform the peer what
>   extensions are locally supported. The Extension-Id MUST also be present
>   in all messages that are defined in a separate DIAMETER specification
>   and have an Extension ID assigned.
>
>   Each DIAMETER extension draft MUST have an IANA assigned extension
>   Idenfier (see section 8.3). The base protocol does not require an
>   Extension-Id since its support is mandatory.
>
>   There MAY be more than one Extension-Id AVP within a DIAMETER
>   Device-Reboot-Ind message. The following values are recognized:
>
>      NASREQ              1 [7]
>      Strong Security     2 [11]
>      Resource Management 3 [29]
>      Mobile-IP           4 [10]
>      Accounting          5 [15]
>
>      Furthermore, servers acting as Redirect or Proxy servers (see
>      Section 6.0) MAY wish to advertise support for ALL possible
>      extensions. Such servers are then responsible for finding a
>      downstream server that supports the extension of a particular
>      message. This is done by including the Extension-Id AVP with a
>      value of zero (0).
>




From owner-aaa-bof@merit.edu  Fri Jan 12 08:55:09 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09002
	for <aaa-archive@odin.ietf.org>; Fri, 12 Jan 2001 08:55:09 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id DED0F5DDE8; Fri, 12 Jan 2001 08:54:50 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id C30E95DDCD; Fri, 12 Jan 2001 08:54:50 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 8FC2B5DDAA
	for <aaa-wg@merit.edu>; Fri, 12 Jan 2001 08:54:49 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA06445;
	Fri, 12 Jan 2001 05:54:45 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA01611;
	Fri, 12 Jan 2001 05:54:44 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id FAA21918;
	Fri, 12 Jan 2001 05:54:43 -0800 (PST)
Date: Fri, 12 Jan 2001 05:51:05 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: RE: Capabilities Negotiation and proxies
To: Fredrik Johansson <fredrik.johansson@ipunplugged.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>, aaa-wg@merit.edu,
        diameter@diameter.org
In-Reply-To: "Your message with ID" <MJEMJBGGCLLDLFFAHLJKKEPHCEAA.fredrik.johansson@ipunplugged.com>
Message-ID: <Roam.SIMC.2.0.6.979307465.14399.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Agreed, but I am still waiting for some level of affirmation from the list
that including the Extension Id would benefit proxies that only support
forwarding and/or redirecting of messages, and extensions are supported on the
home servers.

Anyone??

PatC
> Hi Pat,
> 
> If there MUST be an Extension-Id AVP in all messages defined in other
> DIAMETER specifications, the the section below:
> 
> "There MAY be more than one Extension-Id AVP within a DIAMETER
>    Device-Reboot-Ind message. The following values are recognized:"
> 
> should be changed to:
> 
> "There MAY be more than one Extension-Id AVP within a DIAMETER message. The
> following values are recognized:"
> 
> Since one can for example use Strong Security together with another
> extension in the same message.
> 
> B.R.
> /Fredrik
> 
> >-----Original Message-----
> >From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
> >Of Pat Calhoun
> >Sent: den 11 januari 2001 01:56
> >To: aaa-wg@merit.edu; diameter@diameter.org
> >Subject: Capabilities Negotiation and proxies
> >
> >
> >All,
> >
> >As discussed a few days ago, a proxy MAY wish to proxy ANY type of message,
> >regardless of the extension. Therefore, the current text in the
> >base protocol
> >does not allow this behavior since it would require that proxies
> >advertise ALL
> >possible extensions.
> >
> >Therefore, I am proposing adding the last paragraph to section 2.5.3.
> >Furthermore, I believe that ALL messages MUST include the
> >extension ID of the
> >particular message. The reason being that a proxy would need to identify a
> >server in the home domain that can handle the message, but it may
> >not recognize
> >the command.
> >
> >Comments? Objections? Proposed Text?
> >
> >PatC
> >
> >2.5.3  Extension-Id AVP
> >
> >   The Extension-Id AVP (AVP Code 258) is of type Unsigned32 and is used
> >   in order to identify a specific DIAMETER extension. This AVP is used
> >   in the Device-Reboot-Ind message in order to inform the peer what
> >   extensions are locally supported. The Extension-Id MUST also be present
> >   in all messages that are defined in a separate DIAMETER specification
> >   and have an Extension ID assigned.
> >
> >   Each DIAMETER extension draft MUST have an IANA assigned extension
> >   Idenfier (see section 8.3). The base protocol does not require an
> >   Extension-Id since its support is mandatory.
> >
> >   There MAY be more than one Extension-Id AVP within a DIAMETER
> >   Device-Reboot-Ind message. The following values are recognized:
> >
> >      NASREQ              1 [7]
> >      Strong Security     2 [11]
> >      Resource Management 3 [29]
> >      Mobile-IP           4 [10]
> >      Accounting          5 [15]
> >
> >      Furthermore, servers acting as Redirect or Proxy servers (see
> >      Section 6.0) MAY wish to advertise support for ALL possible
> >      extensions. Such servers are then responsible for finding a
> >      downstream server that supports the extension of a particular
> >      message. This is done by including the Extension-Id AVP with a
> >      value of zero (0).
> >
> 





From owner-aaa-bof@merit.edu  Fri Jan 12 11:34:07 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11835
	for <aaa-archive@odin.ietf.org>; Fri, 12 Jan 2001 11:34:06 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id CF9505DEAD; Fri, 12 Jan 2001 11:33:18 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id BD7E95DEAC; Fri, 12 Jan 2001 11:33:18 -0500 (EST)
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by segue.merit.edu (Postfix) with SMTP id 312B95DEA5
	for <aaa-wg@merit.edu>; Fri, 12 Jan 2001 11:33:15 -0500 (EST)
Received: (qmail 15870 invoked by uid 500); 12 Jan 2001 16:35:02 -0000
Date: Fri, 12 Jan 2001 10:35:01 -0600
From: David Frascone <dave@frascone.com>
To: aaa-wg@merit.edu, diameter@diameter.org
Subject: Comments on draft-calhoun-diameter-18.txt
Message-ID: <20010112103501.H14405@newman.frascone.com>
Mail-Followup-To: aaa-wg@merit.edu, diameter@diameter.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-encrypt-payload: no
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


Ok, here are my comments.  Some are nits, others are what *I* think needs
to change.

---------

General:

	The difference between Request/Answer and Query/Reply was never
	defined.

Section 1.0 Introduction

     Editorial/Nit
	The "required features" bullets all have a strange voice.  They're 
	clauses, but not necessarily noun clauses.  The prepositions have
	to go.  For example, I'd change the last one to:
	
	- Exchanges resource usage information, which MAY be used for
	  accounting purposes, capacity planning, etc.


Section 2.1 Header Format

>   The base DIAMETER protocol is run over SCTP [26] port 1812.
>   Implementations MAY send packets from any source port, but MUST be
>   prepared to receive packets on port 1812. When a request is received,
>   in order to send a reply, the source and destination ports in the
>   reply are reversed. Note that the source and destination addresses
>   used in request and replies MAY be any of the peer's valid IP
>   addresses.

>   A given DIAMETER process SHOULD use the same port number to send all
>   messages to aid in identifying which process sent a given message.
>   More than one DIAMETER process MAY exist within a single host, so the
>   sender's port number is needed to discriminate them.


	Since the servers MUST run on port 1812, their can *not* be multiple
	servers on a single host.  So, I think the second paragraph should
	be deleted.


PCC:
	Since Diameter no longer runs over UDP, there is no reason to keep
	PCC for transport-layer RADIUS compatibility.

	I realize that to keep the words 16 bit (at least) aligned, Diameter
	will end up with 13 bits of flags, but I think that is better than
	wasting 8 on a PCC.


2.2.1 AVP Header

>   The AVP Format is shown below and MUST be sent in network byte order.

	Nit:  It's a run-on (or strangely worded) sentence.

	*Some* fields must be sent in network byte order (i.e. data may
	or may not be).  So, I think that part needs to be removed from
	the sentence, and stated in the individual fields that *are* sent
	in network byte order.

  AVP Length

	Nit: "Attribute" and "Invalid" don't need to be capitalized.

	Perhaps "invalid attribute length" needs to be defined (i.e.
	zero, less than the maximum header size, greater than the maximum
	message size, etc)

  AVP Flags

	"Home server" is used here, and has not been defined.  I think
	we need to either define "Home server", or use a different name.
        "Logical destination" is also used to refer to a "Home server"
        Perhaps this is a better term.


2.2.2 Optional Header Elements

>   The AVP Header consists of several optional fields. These fields are
>   only present if their respective bit-flags are enabled.

	change to:

	The AVP Header contains one optional field, the Vendor-ID.  This
	field is only present if the 'V' bit is set.

2.2.3 AVP Value Formats

	"Value field" and "Data field" are used interchangeably.  We should
	pick one.

		
3.3 Session-Timeout AVP

	The last line in the section does not need to be there.  The zero
	case was defined in the previous paragraph.

6.4.x Proxy-State

	The Proxy-Address AVP and Proxy-Info AVP both refer to section
	6.4.4 for descriptions of them.  There are no descriptions there.

7.1 Hop-by-Hop Security

	The phrase "similar to the method employed by the RADIUS protocol."
	should be removed.  The only similarity to RADIUS is that the
	data is encrypted by moving the MD5 hash around.  Since we're probably
	going to be using AES, I think this phrase is unnecessary.

7.1.2.1.1
	
	The payload hiding is not backward compatible with RADIUS.  (The
	encryption algorithm is, but since RADIUS wouldn't know what to
	do with the packet, I think this sentence is misleading)


Ok, I think that's it.  Sorry it's so long.  I guess I'm more opinionated
that I thought.


-Dave





From owner-aaa-bof@merit.edu  Fri Jan 12 17:34:00 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26198
	for <aaa-archive@odin.ietf.org>; Fri, 12 Jan 2001 17:34:00 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id AF4985DE93; Fri, 12 Jan 2001 17:31:35 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 902405DE96; Fri, 12 Jan 2001 17:31:35 -0500 (EST)
Received: from gate.internaut.com (unknown [64.38.134.108])
	by segue.merit.edu (Postfix) with ESMTP id F014A5DE93
	for <aaa-wg@merit.edu>; Fri, 12 Jan 2001 17:31:33 -0500 (EST)
Received: from e1kj2 (kidneybean [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0CMSGR19277
	for <aaa-wg@merit.edu>; Fri, 12 Jan 2001 14:28:16 -0800
From: "Bernard Aboba" <aboba@internaut.com>
To: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: Meetings during 50th IETF in Minneapolis
Date: Fri, 12 Jan 2001 14:31:42 -0800
Message-ID: <OJEJKOMOEAKLMOILFCPJCEIMDOAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I'm about to submit a request for meeting slots for the AAA WG in
Minneapolis.  We will meet twice.  If you have any agenda items or specific
conflicts with other WGs that you would like to avoid, please let me know.

- Bernard




From owner-aaa-bof@merit.edu  Fri Jan 12 17:34:31 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26215
	for <aaa-archive@odin.ietf.org>; Fri, 12 Jan 2001 17:34:30 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 55FB55DEAB; Fri, 12 Jan 2001 17:32:32 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 42B815DEA4; Fri, 12 Jan 2001 17:32:32 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 05D5E5DEA3
	for <aaa-wg@merit.edu>; Fri, 12 Jan 2001 17:32:31 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA02913;
	Fri, 12 Jan 2001 14:32:29 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA20881;
	Fri, 12 Jan 2001 14:32:28 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA05568;
	Fri, 12 Jan 2001 14:32:25 -0800 (PST)
Date: Fri, 12 Jan 2001 14:28:48 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: Re: Comments on draft-calhoun-diameter-18.txt
To: David Frascone <dave@frascone.com>
Cc: aaa-wg@merit.edu, diameter@diameter.org
In-Reply-To: "Your message with ID" <20010112103501.H14405@newman.frascone.com>
Message-ID: <Roam.SIMC.2.0.6.979338528.23847.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> 	The difference between Request/Answer and Query/Reply was never
> 	defined.

It is specified in the framework document.

> 
> Section 1.0 Introduction
> 
>      Editorial/Nit
> 	The "required features" bullets all have a strange voice.  They're 
> 	clauses, but not necessarily noun clauses.  The prepositions have
> 	to go.  For example, I'd change the last one to:
> 	
> 	- Exchanges resource usage information, which MAY be used for
> 	  accounting purposes, capacity planning, etc.

Thanks, those bullet items did require a rework.

> 
> 
> Section 2.1 Header Format
> 
> >   A given DIAMETER process SHOULD use the same port number to send all
> >   messages to aid in identifying which process sent a given message.
> >   More than one DIAMETER process MAY exist within a single host, so the
> >   sender's port number is needed to discriminate them.
> 
> 
> 	Since the servers MUST run on port 1812, their can *not* be multiple
> 	servers on a single host.  So, I think the second paragraph should
> 	be deleted.
hmmmm.... I am not sure about removing this one. Anyone have an issue with
removing it?

> 
> 
> PCC:
> 	Since Diameter no longer runs over UDP, there is no reason to keep
> 	PCC for transport-layer RADIUS compatibility.
> 
> 	I realize that to keep the words 16 bit (at least) aligned, Diameter
> 	will end up with 13 bits of flags, but I think that is better than
> 	wasting 8 on a PCC.

I would MUCH prefer make the version field be 8 bits and the flags field be 8
bits. Anyone else?

>   AVP Flags
> 
> 	"Home server" is used here, and has not been defined.  I think
> 	we need to either define "Home server", or use a different name.
>         "Logical destination" is also used to refer to a "Home server"
>         Perhaps this is a better term.

Home Server will be in the Terminology section of the new Framework document.

> 7.1 Hop-by-Hop Security
> 
> 	The phrase "similar to the method employed by the RADIUS protocol."
> 	should be removed.  The only similarity to RADIUS is that the
> 	data is encrypted by moving the MD5 hash around.  Since we're probably
> 	going to be using AES, I think this phrase is unnecessary.

Well, the app level security, which makes use of shared secrets, are similar
to those in RADIUS. However, given that the authentication is much stronger
than RADIUS, it probably doesn't do DIAMETER justice. I will remove it.

Thanks for your comments!

PatC




From owner-aaa-bof@merit.edu  Fri Jan 12 17:35:11 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26242
	for <aaa-archive@odin.ietf.org>; Fri, 12 Jan 2001 17:35:11 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 120655DEB6; Fri, 12 Jan 2001 17:33:33 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id F10C85DEB9; Fri, 12 Jan 2001 17:33:32 -0500 (EST)
Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139])
	by segue.merit.edu (Postfix) with ESMTP id AC2D15DEB6
	for <aaa-wg@merit.edu>; Fri, 12 Jan 2001 17:33:31 -0500 (EST)
Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21)
	id <CP2RVS2L>; Fri, 12 Jan 2001 17:25:50 -0500
Message-ID: <A3617F281546D411958C00D0B760121C01274820@bor.ellacoya.com>
From: "Weiss, Walter" <wweiss@ellacoya.com>
To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>,
        David Spence <DSpence@Interlinknetworks.com>
Cc: AAA Working Group <aaa-wg@merit.edu>
Subject: RE: Choice of Data Model SMI vs XML vs. UML
Date: Fri, 12 Jan 2001 17:25:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C07CE6.9DF2B468"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C07CE6.9DF2B468
Content-Type: text/plain;
	charset="iso-8859-1"

I am somewhat baffled by this whole discussion. There is a clear trend to
move service intelligence to the edges. The configuration is not limited to
user identity, but nearly every aspect network usage from Tunnels to QoS to
Security to service access and forwarding rules. Many or all of these will
be keyed off of a user profile.

With this in mind, what kind of framework do we want that will support all
these capabilities. I would submit that a vertical model that assumes that a
network edge device will be configured by a large cross-section of protocols
(User stuff with Diameter, QoS with COPS, Security with SNMP, and service
access with SIP) is doomed to failure because of the implicit
inter-relationships between these technologies and the complexity of
configuration and management.

If the argument is that Diameter is only going to support a very restrictive
set of functions, specified with a relatively small set of attributes, I
have to agree with sentiment that a data modeling exercise is not worth the
effort for this WG. I would also predict that the protocol will be obsolete
before it is deployed (per the previous paragraph).

If, in contrast, there is an implicit goal in AAA to (eventually) support an
extensible set of capabilities, including (but not limited to) those listed
above, we face an ever more complex set of relationships between existing
and newly defined attributes that MUST be facilitated by structured data
(such as objects), reuse (as with inheritance and encapsulation) and well
defined relationships between data structures (associations or pointers).

If the WG conclude that the previous paragraph is the preferred approach,
there have been numerous comments outlining XML's inability to support reuse
and relationships as well as other limitations. This leaves us with a two
alternatives, SPPI and SMIng. I actually don't have a preference between the
two, but I would say if that if this WG is willing to be gated by the
standardizing of SMIng than that would be the better choice. If not, SPPI is
the less optimal but more immediate alternative that SMIng is supposed to be
backward compatible with.

regards,

-Walter
 
> -----Original Message-----
> From: Pat Calhoun [mailto:Pat.Calhoun@Eng.Sun.COM]
> Sent: Friday, January 05, 2001 10:04 AM
> To: David Spence
> Cc: AAA Working Group
> Subject: Re: Choice of Data Model SMI vs XML vs. UML
> 
> 
> > 1. SMI Derivative vs. XML
> > 
> >    An advantage of using some derivative of SMI over XML is 
> that the 
> >    "formal specification" can actually be implemented in the edge 
> >    device.  This improves interoperability and allows interworking 
> >    between tools that use different protocols.
> > 
> > 2. Which derivative of SMI to use
> >    
> >    I don't have strong feelings as to which SMI derivative 
> is best.  We 
> >    chose SPPI for draft-spence-aaa-nas-data-model-00.txt 
> because it was 
> >    designed for policy provisioning, is compatible with 
> COPS (more on 
> >    this at item 3, below),  and is somewhat more mature 
> than SMIng (has 
> >    passed WG last call and is ready for IETF last call).
> >    
> >    The AAA WG may prefer to be more forward looking and use 
> SMIng or to 
> >    opt for greater maturity and use SMI v2.
> > 
> 
> Whatever the WG decides, it MUST be something mature, and 
> currently work in
> progress. 
> 
> > 3. Interworking COPS and DIAMETER
> >    
> >    If the AAA WG chooses XML or chooses an SMI derivative 
> for formal 
> >    notation only without providing a protocol mapping, then the 
> >    following problem arises.
> >    
> >    Suppose an edge device wishes to provide both network access and 
> >    premium QoS.  It would be nice to be able to obtain a single 
> >    admission decision covering both the network access and 
> the premium 
> >    QoS with a single request.  It is troublesome to the ISP 
> to allocate 
> >    QoS resources and then deny access or to create an 
> access session and 
> >    then have to terminate it because the QoS request 
> failed.  If the 
> >    edge device has to use DIAMETER to obtain the network access 
> >    admission decision and COPS to obtain the QoS admission 
> decision, it 
> >    will be very difficult to coordinate the two decisions.  If this 
> >    happens, someone might be tempted to doubt the IETF's wisdom in 
> >    standardizing two protocols where one might have sufficed.
> >    
> >    Of course, if the two protocols use the same data model, 
> then the 
> >    problem goes away.  Either protocol could be used for 
> either type of 
> >    request, so the edge device could request the two 
> related services in 
> >    a single message using either protocol.
> >    
> >    But if the two protocols do not use the same data model, then it 
> >    might be a good idea to create an escape mechanism.  Could we at 
> >    least define a DIAMETER AVP type of COPS message or COPS 
> object which 
> >    means, "shell out to the part of the AAA server that understands 
> >    COPS, process this thing and then return"?  That way, at 
> least, the 
> >    two requests could be piggybacked onto the same message 
> so that a 
> >    sophisticated enough AAA server could process them together.
> 
> Just to be clear, I am not sure how allowing the dictionary 
> and other config
> files), and the documentation to specify message formats in 
> XML or SMI to
> really help interworking of protocols on the wire :(
> 
> The scenario you described above *will* happen, and in the 
> cases that I've
> seen, the local PDP will contact the local DIAMETER server to 
> retrieve user
> profile information, since the information is in the user's 
> home network and
> COPS doesn't do inter-domain. > 
> > 4. What combinations of attributes make sense?
> >    
> >    A problem which RADIUS leaves unaddressed and which so 
> far has not 
> >    been addressed by DIAMETER is the question of which 
> attributes can 
> >    and can not be meaningfully combined in a message.  Or, 
> to put it 
> >    another way, which attributes pertain to which services. 
>  Here's an 
> >    example.
> >    
> >    The description of the Termination-Action attribute in 
> RFC 2865 says 
> >    simply, 
> >    
> >       "This Attribute indicates what action the NAS should 
> take when the 
> >       specified service is completed.  It is only used in 
> Access-Accept 
> >       packets."
> >       
> >    The RFC does not specify which services the attribute 
> applies to.  I 
> >    assume it applies to the Login service.  Could it also 
> apply to the 
> >    Framed service?  If I combine it with attributes such as 
> >    Framed-Protocol, Framed-IP-Address, and 
> Framed-IP-Netmask, what am I 
> >    expecting the NAS to do?
> >    
> >    A data model provides an answer to this sort of question 
> by grouping 
> >    elementary attributes by service.  If an attribute applies to a 
> >    service it is included with the service, either directly or by 
> >    association.  If an attribute does not apply, then it is 
> not included 
> >    in that part of the model.  Ambiguities are resolved, and 
> >    interoperability is enhanced.
> 
> I agree that the specifications must be clear. If in theNAS 
> dial-up world
> certain ambiguities still exist, then let's fix them in the spec. One
> possibility is to make use of different command sets for PPP 
> and terminal
> server. In fact, this would REALLY clean up the extension IMHO.
> 
> PatC
> 
> 

------_=_NextPart_001_01C07CE6.9DF2B468
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: Choice of Data Model SMI vs XML vs. UML</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I am somewhat baffled by this whole discussion. There =
is a clear trend to move service intelligence to the edges. The =
configuration is not limited to user identity, but nearly every aspect =
network usage from Tunnels to QoS to Security to service access and =
forwarding rules. Many or all of these will be keyed off of a user =
profile.</FONT></P>

<P><FONT SIZE=3D2>With this in mind, what kind of framework do we want =
that will support all these capabilities. I would submit that a =
vertical model that assumes that a network edge device will be =
configured by a large cross-section of protocols (User stuff with =
Diameter, QoS with COPS, Security with SNMP, and service access with =
SIP) is doomed to failure because of the implicit inter-relationships =
between these technologies and the complexity of configuration and =
management.</FONT></P>

<P><FONT SIZE=3D2>If the argument is that Diameter is only going to =
support a very restrictive set of functions, specified with a =
relatively small set of attributes, I have to agree with sentiment that =
a data modeling exercise is not worth the effort for this WG. I would =
also predict that the protocol will be obsolete before it is deployed =
(per the previous paragraph).</FONT></P>

<P><FONT SIZE=3D2>If, in contrast, there is an implicit goal in AAA to =
(eventually) support an extensible set of capabilities, including (but =
not limited to) those listed above, we face an ever more complex set of =
relationships between existing and newly defined attributes that MUST =
be facilitated by structured data (such as objects), reuse (as with =
inheritance and encapsulation) and well defined relationships between =
data structures (associations or pointers).</FONT></P>

<P><FONT SIZE=3D2>If the WG conclude that the previous paragraph is the =
preferred approach, there have been numerous comments outlining XML's =
inability to support reuse and relationships as well as other =
limitations. This leaves us with a two alternatives, SPPI and SMIng. I =
actually don't have a preference between the two, but I would say if =
that if this WG is willing to be gated by the standardizing of SMIng =
than that would be the better choice. If not, SPPI is the less optimal =
but more immediate alternative that SMIng is supposed to be backward =
compatible with.</FONT></P>

<P><FONT SIZE=3D2>regards,</FONT>
</P>

<P><FONT SIZE=3D2>-Walter</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Pat Calhoun [<A =
HREF=3D"mailto:Pat.Calhoun@Eng.Sun.COM">mailto:Pat.Calhoun@Eng.Sun.COM</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, January 05, 2001 10:04 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: David Spence</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: AAA Working Group</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: Choice of Data Model SMI vs XML =
vs. UML</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 1. SMI Derivative vs. XML</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; An advantage of using =
some derivative of SMI over XML is </FONT>
<BR><FONT SIZE=3D2>&gt; that the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; &quot;formal =
specification&quot; can actually be implemented in the edge </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; device.&nbsp; This =
improves interoperability and allows interworking </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; between tools that use =
different protocols.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 2. Which derivative of SMI to use</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; I don't have strong =
feelings as to which SMI derivative </FONT>
<BR><FONT SIZE=3D2>&gt; is best.&nbsp; We </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; chose SPPI for =
draft-spence-aaa-nas-data-model-00.txt </FONT>
<BR><FONT SIZE=3D2>&gt; because it was </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; designed for policy =
provisioning, is compatible with </FONT>
<BR><FONT SIZE=3D2>&gt; COPS (more on </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; this at item 3, =
below),&nbsp; and is somewhat more mature </FONT>
<BR><FONT SIZE=3D2>&gt; than SMIng (has </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; passed WG last call and =
is ready for IETF last call).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; The AAA WG may prefer to =
be more forward looking and use </FONT>
<BR><FONT SIZE=3D2>&gt; SMIng or to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; opt for greater maturity =
and use SMI v2.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Whatever the WG decides, it MUST be something =
mature, and </FONT>
<BR><FONT SIZE=3D2>&gt; currently work in</FONT>
<BR><FONT SIZE=3D2>&gt; progress. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 3. Interworking COPS and DIAMETER</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; If the AAA WG chooses =
XML or chooses an SMI derivative </FONT>
<BR><FONT SIZE=3D2>&gt; for formal </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; notation only without =
providing a protocol mapping, then the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; following problem =
arises.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; Suppose an edge device =
wishes to provide both network access and </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; premium QoS.&nbsp; It =
would be nice to be able to obtain a single </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; admission decision =
covering both the network access and </FONT>
<BR><FONT SIZE=3D2>&gt; the premium </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; QoS with a single =
request.&nbsp; It is troublesome to the ISP </FONT>
<BR><FONT SIZE=3D2>&gt; to allocate </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; QoS resources and then =
deny access or to create an </FONT>
<BR><FONT SIZE=3D2>&gt; access session and </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; then have to terminate =
it because the QoS request </FONT>
<BR><FONT SIZE=3D2>&gt; failed.&nbsp; If the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; edge device has to use =
DIAMETER to obtain the network access </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; admission decision and =
COPS to obtain the QoS admission </FONT>
<BR><FONT SIZE=3D2>&gt; decision, it </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; will be very difficult =
to coordinate the two decisions.&nbsp; If this </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; happens, someone might =
be tempted to doubt the IETF's wisdom in </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; standardizing two =
protocols where one might have sufficed.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; Of course, if the two =
protocols use the same data model, </FONT>
<BR><FONT SIZE=3D2>&gt; then the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; problem goes away.&nbsp; =
Either protocol could be used for </FONT>
<BR><FONT SIZE=3D2>&gt; either type of </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; request, so the edge =
device could request the two </FONT>
<BR><FONT SIZE=3D2>&gt; related services in </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; a single message using =
either protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; But if the two protocols =
do not use the same data model, then it </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; might be a good idea to =
create an escape mechanism.&nbsp; Could we at </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; least define a DIAMETER =
AVP type of COPS message or COPS </FONT>
<BR><FONT SIZE=3D2>&gt; object which </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; means, &quot;shell out =
to the part of the AAA server that understands </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; COPS, process this thing =
and then return&quot;?&nbsp; That way, at </FONT>
<BR><FONT SIZE=3D2>&gt; least, the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; two requests could be =
piggybacked onto the same message </FONT>
<BR><FONT SIZE=3D2>&gt; so that a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; sophisticated enough AAA =
server could process them together.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Just to be clear, I am not sure how allowing =
the dictionary </FONT>
<BR><FONT SIZE=3D2>&gt; and other config</FONT>
<BR><FONT SIZE=3D2>&gt; files), and the documentation to specify =
message formats in </FONT>
<BR><FONT SIZE=3D2>&gt; XML or SMI to</FONT>
<BR><FONT SIZE=3D2>&gt; really help interworking of protocols on the =
wire :(</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The scenario you described above *will* happen, =
and in the </FONT>
<BR><FONT SIZE=3D2>&gt; cases that I've</FONT>
<BR><FONT SIZE=3D2>&gt; seen, the local PDP will contact the local =
DIAMETER server to </FONT>
<BR><FONT SIZE=3D2>&gt; retrieve user</FONT>
<BR><FONT SIZE=3D2>&gt; profile information, since the information is =
in the user's </FONT>
<BR><FONT SIZE=3D2>&gt; home network and</FONT>
<BR><FONT SIZE=3D2>&gt; COPS doesn't do inter-domain. &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 4. What combinations of attributes make =
sense?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; A problem which RADIUS =
leaves unaddressed and which so </FONT>
<BR><FONT SIZE=3D2>&gt; far has not </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; been addressed by =
DIAMETER is the question of which </FONT>
<BR><FONT SIZE=3D2>&gt; attributes can </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; and can not be =
meaningfully combined in a message.&nbsp; Or, </FONT>
<BR><FONT SIZE=3D2>&gt; to put it </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; another way, which =
attributes pertain to which services. </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Here's an </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; example.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; The description of the =
Termination-Action attribute in </FONT>
<BR><FONT SIZE=3D2>&gt; RFC 2865 says </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; simply, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&quot;This Attribute indicates what action the NAS should </FONT>
<BR><FONT SIZE=3D2>&gt; take when the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
specified service is completed.&nbsp; It is only used in </FONT>
<BR><FONT SIZE=3D2>&gt; Access-Accept </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
packets.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; The RFC does not specify =
which services the attribute </FONT>
<BR><FONT SIZE=3D2>&gt; applies to.&nbsp; I </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; assume it applies to the =
Login service.&nbsp; Could it also </FONT>
<BR><FONT SIZE=3D2>&gt; apply to the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; Framed service?&nbsp; If =
I combine it with attributes such as </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; Framed-Protocol, =
Framed-IP-Address, and </FONT>
<BR><FONT SIZE=3D2>&gt; Framed-IP-Netmask, what am I </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; expecting the NAS to =
do?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; A data model provides an =
answer to this sort of question </FONT>
<BR><FONT SIZE=3D2>&gt; by grouping </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; elementary attributes by =
service.&nbsp; If an attribute applies to a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; service it is included =
with the service, either directly or by </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; association.&nbsp; If an =
attribute does not apply, then it is </FONT>
<BR><FONT SIZE=3D2>&gt; not included </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; in that part of the =
model.&nbsp; Ambiguities are resolved, and </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; interoperability is =
enhanced.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I agree that the specifications must be clear. =
If in theNAS </FONT>
<BR><FONT SIZE=3D2>&gt; dial-up world</FONT>
<BR><FONT SIZE=3D2>&gt; certain ambiguities still exist, then let's fix =
them in the spec. One</FONT>
<BR><FONT SIZE=3D2>&gt; possibility is to make use of different command =
sets for PPP </FONT>
<BR><FONT SIZE=3D2>&gt; and terminal</FONT>
<BR><FONT SIZE=3D2>&gt; server. In fact, this would REALLY clean up the =
extension IMHO.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; PatC</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C07CE6.9DF2B468--



From owner-aaa-bof@merit.edu  Sun Jan 14 03:40:00 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05054
	for <aaa-archive@odin.ietf.org>; Sun, 14 Jan 2001 03:40:00 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id BF1265DDC1; Sun, 14 Jan 2001 03:39:25 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A0A7F5DDC7; Sun, 14 Jan 2001 03:39:25 -0500 (EST)
Received: from gate.internaut.com (unknown [64.38.134.108])
	by segue.merit.edu (Postfix) with ESMTP id B7E775DDC1
	for <aaa-wg@merit.edu>; Sun, 14 Jan 2001 03:39:23 -0500 (EST)
Received: from e1kj2 (kidneybean [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0E8ZwR01596
	for <aaa-wg@merit.edu>; Sun, 14 Jan 2001 00:35:58 -0800
From: "Bernard Aboba" <aboba@internaut.com>
To: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: Clarification of discussion on Data Models
Date: Sun, 14 Jan 2001 00:39:33 -0800
Message-ID: <OJEJKOMOEAKLMOILFCPJOEKFDOAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

There seems to be some confusion about what exactly we are trying to do with
Data Modelling.

I would like to try to clarify one or two things.

It seems to me that DIAMETER, in its present form, can be used to transmit
attributes containing SPPI, SMIng, SMI, XML or any other chosen format by
defining an octet-string attribute to encapsulate these formats.

As a result I don't think the discussion is about whether we can encode
SPPI, SMIng, SMI, XML or anything else in attributes. We can do this.

Secondly, I don't think this debate is about the DIAMETER wire protocol. I
say this because I haven't noticed anyone suggesting that we change the wire
protocol to make it more compatible with any of the above formats.

So what are we discussing, exactly?

The design team discussion took off from some observations made about
difficulties encountered in RADIUS.
The RADIUS Tunnel attributes, though they constituted only a relatively
modest departure from the previous attribute set, could not easily be
accomodated by many implementations. UI code had to be re-written;
dictionary formats had to be extended; packet sniffers had to be updated,
etc. Since the whole idea of the RADIUS dictionary was to enable addition of
new attributes without such code changes, this seemed to expose a RADIUS
limitation that was likely to only get worse with time. The issue was deemed
serious enough to be worth fixing in DIAMETER.

So a problem that the design team took on was to find a way of increasing
the flexiblity of the DIAMETER dictionary so that you really could add
attributes, even more complicated ones, without having to change code. Note
that the goal wasn't to be able to express attributes of infinite
complexity, but merely to be able to express the most complicated attributes
that we believed would appear within the problem domain.

Secondly, there was a discussion of how the DIAMETER protocol itself should
be defined. The BNF notation introduced in the drafts didn't seem entirely
satisfactory, so the question was how this could be improved. Note that the
goal wasn't to change the protocol, merely to more rigourously define the
protocol as it exists.

Erik Guttman, Juergen Schoenwaelder, and David Spence have taken on these
problems and come up with potential solutions. So in evaluating these
solutions it's worthwhile to compare them against the problem space.

To my mind, in this exercise, as in everything else we do, our goal is NOT
to figure out how much functionality we can cram into DIAMETER. It is to
figure out the simplest, most elegant solution that can get the job done.

RADIUS, as limited as it is, is very widely deployed because of its
simplicity, and as a result may prove exceedingly difficult to dislodge. You
cannot defeat a lightweight, highly mobile guerilla army during monsoon
season by bringing in heavy armour -- you'll just get stuck in the mud.
You've got to be lightweight and mobile yourself.




From owner-aaa-bof@merit.edu  Mon Jan 15 00:55:14 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15580
	for <aaa-archive@odin.ietf.org>; Mon, 15 Jan 2001 00:55:14 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 6E3C05DD8E; Mon, 15 Jan 2001 00:54:46 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 577775DD91; Mon, 15 Jan 2001 00:54:46 -0500 (EST)
Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103])
	by segue.merit.edu (Postfix) with ESMTP id 547B15DD8E
	for <aaa-wg@merit.edu>; Mon, 15 Jan 2001 00:54:45 -0500 (EST)
Received: from postal.research.att.com (postal.research.att.com [135.207.23.30])
	by mail-green.research.att.com (Postfix) with ESMTP
	id D08A51E074; Mon, 15 Jan 2001 00:54:44 -0500 (EST)
Received: from smb.research.att.com (secure.research.att.com [135.207.24.10])
	by postal.research.att.com (8.8.7/8.8.7) with ESMTP id AAA21110;
	Mon, 15 Jan 2001 00:54:37 -0500 (EST)
Received: from smb.research.att.com (localhost.research.att.com [127.0.0.1])
	by smb.research.att.com (Postfix) with ESMTP
	id 7912535DCC; Sun, 14 Jan 2001 22:19:16 -0500 (EST)
X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI]
From: "Steven M. Bellovin" <smb@research.att.com>
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: Bernard Aboba <aboba@internaut.com>,
        "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: Re: Security proposals for Interim meeting, Feburary 7, 2001 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 14 Jan 2001 22:19:16 -0500
Message-Id: <20010115031916.7912535DCC@smb.research.att.com>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

In message <Roam.SIMC.2.0.6.979236048.23304.pcalhoun@nasnfs>, Pat Calhoun write
s:
>Bernard,
>
>Should I assume from your e-mail that hop-by-hop is out in the base spec? I
>think discounting hop security is a mistake. Should I bring a contribution
>detailing this method?

Not at all.  In fact, the GSS-API and IPsec solutions are almost pure 
hop-by-hop.  (I say "almost" because I could probably construct an 
end-to-end Kerberos solution, if the proxies forwarded TGT requests to a 
distant Kerberos server.)


		--Steve Bellovin, http:/www.research.att.com/~smb





From owner-aaa-bof@merit.edu  Mon Jan 15 02:09:33 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29205
	for <aaa-archive@odin.ietf.org>; Mon, 15 Jan 2001 02:09:33 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 885EC5DDB0; Mon, 15 Jan 2001 02:09:14 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 758F25DDF9; Mon, 15 Jan 2001 02:09:14 -0500 (EST)
Received: from cisco.com (pilu.cisco.com [192.122.173.199])
	by segue.merit.edu (Postfix) with ESMTP id E2F005DDB0
	for <aaa-wg@merit.edu>; Mon, 15 Jan 2001 02:09:11 -0500 (EST)
Received: (from kaushik@localhost)
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA29699;
	Mon, 15 Jan 2001 12:34:54 +0530 (IST)
From: Kaushik Narayan <kaushik@cisco.com>
Message-Id: <200101150704.MAA29699@cisco.com>
Subject: Re: Security proposals for Interim meeting, Feburary 7, 2001
To: smb@research.att.com (Steven M. Bellovin)
Date: Mon, 15 Jan 2001 12:34:54 +0530 (IST)
Cc: Pat.Calhoun@eng.sun.com (Pat Calhoun), aboba@internaut.com (Bernard Aboba),
        aaa-wg@merit.edu (Aaa-Wg@Merit. Edu)
In-Reply-To: <20010115031916.7912535DCC@smb.research.att.com> from "Steven M. Bellovin" at Jan 14, 2001 10:19:16 PM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

hi!

   Actually the kerberos solution provides both end-to-end and 
   and hop-by-hop. The TGT and service principal requests would be 
   sent directly from the Diameter client (NAS or first proxy) to
   the homerealm KDC. In case of TGT, Diameter client sends request 
   to local KDC which would be relayed to remote KDC. For service 
   principal ticket, Diameter client sends request 
   (KRB_TGS_REQ/KRB_TGS_REP) directly to remote realm KDC, proxies 
   don't relay tickets.
       The key negotiation (KRB_AP_REQ/KRB_AP_REP) messages carried in the 
   Diameter AVPs and would be forwared by proxies. The kerberos solution 
   can create security associations between any end-to-end diameter peers 
   or adjacent diameter peers. 

 kaushik!

  


> 
> In message <Roam.SIMC.2.0.6.979236048.23304.pcalhoun@nasnfs>, Pat Calhoun write
> s:
> >Bernard,
> >
> >Should I assume from your e-mail that hop-by-hop is out in the base spec? I
> >think discounting hop security is a mistake. Should I bring a contribution
> >detailing this method?
> 
> Not at all.  In fact, the GSS-API and IPsec solutions are almost pure 
> hop-by-hop.  (I say "almost" because I could probably construct an 
> end-to-end Kerberos solution, if the proxies forwarded TGT requests to a 
> distant Kerberos server.)
> 
> 
> 		--Steve Bellovin, http:/www.research.att.com/~smb
> 
> 
> 
> 




From owner-aaa-bof@merit.edu  Tue Jan 16 06:24:18 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08048
	for <aaa-archive@odin.ietf.org>; Tue, 16 Jan 2001 06:24:18 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 457775DD8C; Tue, 16 Jan 2001 06:23:48 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 2371F5DDA0; Tue, 16 Jan 2001 06:23:48 -0500 (EST)
Received: from ness.sophia.Sema.fr (ness.sophia.sema.fr [195.101.208.115])
	by segue.merit.edu (Postfix) with ESMTP id 960E35DD8C
	for <aaa-wg@merit.edu>; Tue, 16 Jan 2001 06:23:45 -0500 (EST)
Received: from sopmes01.sophia.sema.fr (sopmes01.sophia.sema.fr) by ness.sophia.Sema.fr
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T5123f53991ac177ed30ee@ness.sophia.Sema.fr>;
 Tue, 16 Jan 2001 12:20:24 +0100
Received: from palmier.sema.fr (palmier.sophia.sema.fr [172.23.126.156]) by sopmes01.sophia.sema.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id DBM4CBBM; Tue, 16 Jan 2001 12:31:01 +0100
Message-Id: <5.0.2.1.0.20010116122113.00aac380@mailserver>
X-Sender: azh@mailserver
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Tue, 16 Jan 2001 12:22:11 +0100
To: "Bernard D. Aboba" <aboba@internaut.com>
From: Alain Zahm <Alain.Zahm@sema.fr>
Subject: Re: Making the hard choices on AAA security
Cc: aaa-wg@merit.edu
In-Reply-To: <Pine.NXT.3.90.1010104070514.277A-100000@internaut.com>
References: <20010104002815.A48730@mx.databus.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

<html>
Hello,<br>
<br>
I haven't been active since now on that list. Being involved in AAA
activity within my company, and following that thread I have a deeper
question on security issues then:<br>
do we need to foresee the handling of delivery denial in DIAMETER? In
other words: do we need to ask a server signing the result of a request?
I understand that might be considered heavy but could become important in
wholesales area.<br>
<br>
If the answer is yes then I think we'll have to think specifying security
at DIAMETER level.<br>
<br>
<br>
At 23:19 03/01/01 -0800, you wrote:<br>
The question of the day is:<br>
<br>
&quot;How simple can we make this and still solve<br>
the problem?&quot;<br>
<br>
&gt; One solution to this problem is the use of<br>
&gt; GSSAPI for end-to-end security for diameter.<br>
&gt; I have been investigating this since the San<br>
&gt; Deigo meeting. The use of GSSAPI would mean <br>
&gt; that implementations need not bind the AAA<br>
&gt; security to a particular mechanism.<br>
<br>
A few questions:<br>
<br>
a. How would GSSAPI work if you need more than<br>
a single round trip? I assume we would carry<br>
the GSSAPI tokens in the AAA request/response<br>
messages, no? Is the restriction to a single<br>
round-trip important or not?<br>
<br>
b. What is the mandatory to implement GSSAPI<br>
method for DIAMETER? KerbV? <br>
<br>
c. Assuming we do this, are we done? In other<br>
words, can we assume we *always* have at least<br>
e2e authentication/integrity protection turned<br>
on, and therefore don't need any hop-by-hop<br>
security? Or do we need password hiding because <br>
we may not always have confidentiality or <br>
hop-by-hop auth/integrity because we don't<br>
cover enough of the message with e2e? <br>
<br>
How simple can we make this and still solve<br>
the problem?<br>
<br>
<br>
-----Original Message-----<br>
From: Bernard Aboba
[<a href="mailto:aboba@internaut.com" eudora="autourl"><font color="#0000FF"><u>mailto:aboba@internaut.com</a></u></font>]<br>
Sent: Wednesday, January 03, 2001 8:22 PM<br>
To: Aaa-Wg@Merit. Edu<br>
Subject: Making the hard choices on AAA security<br>
<br>
<br>
In the spirit of the AAA WG, which has always chosen<br>
to tackle the hard problems early, I would like to<br>
pose the following question:<br>
<br>
&quot;What is the minimum security functionality that we<br>
need to meet the requirements?&quot;<br>
<br>
Notice, I didn't ask:<br>
<br>
&quot;How much security functionality can we cram in?&quot;<br>
<br>
In discussing security there may be an assumption <br>
that we can have lots of security options.<br>
<br>
For example, we might make shared secret<br>
mandatory, throw in various options on hop-by-hop<br>
(IPSEC, SSL), and for good measure specify a<br>
couple of ways to do e2e security (CMS, Kerberos). <br>
<br>
Therein lies the road to h*ll. <br>
<br>
As Jeff Case has so eloquently stated, optional<br>
features are bad. You have to implement them <br>
because someone else might want to use them, <br>
but you can never be guaranteed to reap the benefits. <br>
<br>
I'd rather have one strong mandatory mechanism than<br>
one weak mandatory one and an optional strong<br>
mechanism. <br>
<br>
So, the question is &quot;what must we have?&quot;<br>
<br>
I think the case has been made that e2e security<br>
is needed in *some* circumstances. Not all<br>
circumstances -- for example, if you use <br>
referal you don't need it. <br>
<br>
Can we live with *one* e2e mechanism being<br>
the *only* security mechanism we support?<br>
If so, which one? If not, why won't this be<br>
adequate? <br>
<br>
And if we do this, can we get rid of the<br>
RADIUS password-hiding mechanism?<br>
<br>
If you think that we need hop by hop security<br>
too, how many of *those* mechanisms do we need?<br>
Can we live with *one* of those? Which one?<br>
<br>
If you think that IPSEC alone will magically<br>
sole our hop by hop security problems, think<br>
about this:<br>
<br>
a. IPSEC transport mode is not very widely<br>
deployed today. In fact, I know of no RADIUS<br>
deployment running over IPSEC. <br>
<br>
b. Specifying IPSEC doesn't guarantee<br>
instant interoperability. It's taken quite a<br>
while to get interoperability between<br>
L2TP/IPSEC implementations. <br>
<br>
To summarize:<br>
<br>
&quot;There is no silver bullet, only hard choices&quot;. <br>
Alain Zahm<br>
<br>
SEMA GROUP TELECOMS<br>
R&amp;D Technical Director<br>
<br>
Route des Lucioles - Les Algorithmes - Pythagore A<br>
BP 279 - 06905 Sophia Antipolis Cedex<br>
Phone: +33 (0)4 93 95 40 66<br>
Mobile: +33 (0)6 89 87 12 49<br>
Mailto: alain.zahm@sema.fr<br>
PGP Key Fingerprint: F468 A906 F511 BFF7 CC8E 5F7C 5B42 2C06 B0C0
EF6B<br>
Web:
<a href="http://www.semagroup.com/" eudora="autourl"><font color="#0000FF"><u>www</a></u></font>.semagroup.<a href="http://www.semagroup.com/" eudora="autourl"><font color="#0000FF"><u>com</a><br>
<a href="http://www.semagroup.com/telecoms" eudora="autourl">www</a></u></font>.semagroup.com/<a href="http://www.semagroup.com/telecoms" eudora="autourl"><font color="#0000FF"><u>telecoms</a></font></u></html>




From owner-aaa-bof@merit.edu  Tue Jan 16 06:40:31 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08202
	for <aaa-archive@odin.ietf.org>; Tue, 16 Jan 2001 06:40:31 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 13B2C5DDAD; Tue, 16 Jan 2001 06:40:15 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id EB7C05DDA4; Tue, 16 Jan 2001 06:40:14 -0500 (EST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by segue.merit.edu (Postfix) with ESMTP id C11F85DDA0
	for <aaa-wg@merit.edu>; Tue, 16 Jan 2001 06:40:13 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08147;
	Tue, 16 Jan 2001 06:40:13 -0500 (EST)
Message-Id: <200101161140.GAA08147@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: aaa-wg@merit.edu
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-aaa-proto-eval-02.txt
Date: Tue, 16 Jan 2001 06:40:12 -0500
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authentication, Authorization and Accounting Working Group of the IETF.

	Title		: Authentication, Authorization, and Accounting:Protocol
                          Evaluation
	Author(s)	: D. Mitton et al.
	Filename	: draft-ietf-aaa-proto-eval-02.txt
	Pages		: 91
	Date		: 15-Jan-01
	
This document represents the process and findings of the AAA WG panel
evaluating protocols proposed against the AAA Network Access Require-
ments [AAAReqts].  Due to time constraints of this report, this document
is not as fully polished as it might have been desired.  But it remains
mostly in this state to document the results as presented.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-aaa-proto-eval-02.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-ietf-aaa-proto-eval-02.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-aaa-proto-eval-02.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="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010115092131.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-aaa-proto-eval-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-aaa-proto-eval-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010115092131.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-aaa-bof@merit.edu  Tue Jan 16 11:28:35 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15520
	for <aaa-archive@odin.ietf.org>; Tue, 16 Jan 2001 11:28:35 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id B7DE35DDB6; Tue, 16 Jan 2001 11:28:16 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A87F15DDB5; Tue, 16 Jan 2001 11:28:16 -0500 (EST)
Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110])
	by segue.merit.edu (Postfix) with ESMTP id A86705DD98
	for <aaa-wg@merit.edu>; Tue, 16 Jan 2001 11:28:15 -0500 (EST)
Received: from phoenix (unknown [198.108.5.3])
	by aaa.interlinknetworks.com (Postfix) with SMTP
	id A99ED75; Tue, 16 Jan 2001 11:28:23 -0500 (EST)
From: "Bob Kopacz" <BKopacz@InterlinkNetworks.com>
To: "Pat Calhoun" <Pat.Calhoun@Eng.Sun.COM>
Cc: "Aaa-Wg" <aaa-wg@merit.edu>
Subject: DIAMETER Base Protocol (Alpha 1)" draft / Minor Comments
Date: Tue, 16 Jan 2001 11:27:48 -0500
Message-ID: <NEBBKEONLKEDJCMHGHPIMEHECAAA.BKopacz@InterlinkNetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pat,

Here's some further minor comments on the "DIAMETER Base
Protocol (Alpha 1)" draft.


Section 2.2.4.1 Example AVP with a Grouped value type
--------------------------------------------------------

This section gives an example of a Grouped-AVP which includes
the User-Name AVP and the Host-IP-Address AVP.  Since the
Host-IP-Address AVP is only present in the DRI packet
(according to section 2.5.4 Host-IP-Address AVP), and since
User-Name cannot be present in a DRI, maybe the example should
be revamped to a non-conflicting group of AVPs.


Section 2.3.1 "Host-Name AVP"
-----------------------------

The Host-Name AVP defines the value as being the "sender's"
identity, and later as the identity of the "originator" of the
Diameter message.

One could, like I did, interpret "sender" and "originator" as
the peer who sent this packet, treating Host-Name AVP as a
"Peer-Name" AVP, where each server in a proxy chain replaced the
AVP value with his name.

But the Host-Name seems to identify the original sender and
not necessarily the immediate sender which may be a proxy.  This
might be stated explicitly, else a proxy implementation may
replace the Host-Name AVP from a received packet with a
Host-Name AVP identifying himself, before forwarding the packet
to the next hop Diameter server.

Maybe some explicit clarifying text could be added, e.g:

    "This AVP identifies the endpoint which originated the 
    Diameter message, i.e. the NAS, home server, or broker.  
    Proxy servers do not modify this AVP".


3.1  Session-Id AVP
-------------------

An email (not mine) from a while back asked some questions about
the Session-ID AVP, i.e. "How is this encoded? All ASCII? A mix
of null-terminated strings and numbers in network byte order?
Something else?"

I think the answer was all ASCII, in network byte order, but
this hasn't made its way into the document.


Section 8.4
------------

Section 8.4 is inconsistent with section 5.2.  Section 8.4
states: 

   As defined in Section 5.2, the Result Code AVP (AVP Code 268) defines
   the values 0-8. ...

The values defined in section 5.2 are no longer 0-8.


Minor Typos/etc:
----------------

Section 6.1  Realm-Based Message Routing, 2nd paragragh:

<<<<<<<<<<<<<< 
   DIAMETER message, by using a DNIS or ANY to Routing-Realm association
>>>>>>>>>>>>>> 
   DIAMETER message, by using a DNIS or ANI to Routing-Realm association


Section  6.2.1  Proxy and Redirect Server handling of requests
 
<<<<<<<<<<<<<<
        contains the identities of the server the message must be
>>>>>>>>>>>>>>
        contains the identities of the server(s) the message must be

 
6.3  Redirect Server, 2nd paragraph:
 
<<<<<<<<<<<<<<
   DIAMETER server that could satisfy the message. The home servers are
   encoded in one or more Redirect-Host-Address. If the Redirect-Host-
>>>>>>>>>>>>>>
   DIAMETER servers that could satisfy the message. The home servers are
   encoded in one or more Redirect-Host-Address AVPs. If the Redirect-Host-

 
6.4  Proxy Server, 4th paragraph: 
 
<<<<<<< at Date + 1307 <<<<<<< [\email\draft-~2.txt + 1310]
   intensive purposes, stateful servers terminate an upstream "session",
>>>>>>> at Date + 1307 >>>>>>> [\ietf\dr03c4~1.txt + 1310]
   intents and purposes, stateful servers terminate an upstream "session",




From owner-aaa-bof@merit.edu  Tue Jan 16 11:44:49 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15964
	for <aaa-archive@odin.ietf.org>; Tue, 16 Jan 2001 11:44:48 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 1441D5DDD5; Tue, 16 Jan 2001 11:44:29 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 039785DDB9; Tue, 16 Jan 2001 11:44:28 -0500 (EST)
Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110])
	by segue.merit.edu (Postfix) with ESMTP id 00E3A5DDD0
	for <aaa-wg@merit.edu>; Tue, 16 Jan 2001 11:44:27 -0500 (EST)
Received: from phoenix (unknown [198.108.5.3])
	by aaa.interlinknetworks.com (Postfix) with SMTP
	id E9FE674; Tue, 16 Jan 2001 11:44:35 -0500 (EST)
From: "Bob Kopacz" <BKopacz@InterlinkNetworks.com>
To: "Pat Calhoun" <Pat.Calhoun@Eng.Sun.COM>
Cc: "Aaa-Wg" <aaa-wg@merit.edu>
Subject: DIAMETER Base Protocol (18-Alpha 1)" draft / 5.0 Error Reporting
Date: Tue, 16 Jan 2001 11:44:00 -0500
Message-ID: <NEBBKEONLKEDJCMHGHPIEEHFCAAA.BKopacz@InterlinkNetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pat,

When reading section 5.0 "Error Reporting" in the "DIAMETER Base
Protocol (Alpha 1)" draft, I came up with a number of questions
about the handling of a bad reply message, which probably means
I'm missing something basic.

Maybe some clarifications could be added to this section.

I fear I'm all wet here, but here's some questions:


Case 1:  NAS -> HomeServer.  NAS detects error.
-----------------------------------------------

We have a NAS talking directly to his Home Server; no proxies
are involved.  The NAS originates a valid *-Request.  The
HomeServer sends a positive *-Answer which the NAS considers
erroneous (e.g. the *-Answer packet is syntactically incorrect;
or the *-Answer packet is syntactically correct but contains an
AVP with an inappropriate value).

I assume that an MRI is intended as a response not just to bad
*-Request and *-Ind packets, but also to bad *-Answer packets.

The NAS, I think, would send an MRI back to the home server with
an appropriate Result-Code.  If the MRI serves no other purpose,
it can at least make its way into the home server's log file, as
an aid to those investigating why sessions aren't being set up.

If the home server maintains session state, he considers this to
be an active session, since he sent a positive reply.  Is the
MRI sufficient to stimulate the home server to release this
active session, or should the NAS also (or instead) send a
Session-Terminate-Request?  (The MRI may not contain enough
information for the home server to make a determination as to
the fate of this session.  For example, if the MRI was in
response to the home server's positive AA-Answer, the home
server can release the session.  If the MRI was in response to
the home server's Session-Terminate-Ind, then the home server
wouldn't release the session.  But the MRI doesn't indicate the
home server's offending packet.  The home server also doesn't 
know if the Identifier value is his or the NAS's).

According to the table in section 5.0, an MRI can be sent only
if the error is of type "Unknown Command".  If so, what can the
NAS send to the Home Server if the error is of type "Unknown
AVP", "Bad AVP Value", or "Extension Error"? According to the
table, the NAS should send some extension-specific error
response, but I don't see any candidates that can be sent in
response to a bad reply.

Does the NAS behave differently if he receives a bad negative
reply rather than a bad positive reply? (e.g. forego sending the
MRI)


Case 2:  NAS -> RoutingProxy -> HomeServer.  NAS detects error.
---------------------------------------------------------------

Same as case 1, but with a proxy in the middle: The NAS
originates a valid *-Request.  The HomeServer sends a positive
*-Answer, which passes through the proxy ok, but which the NAS
considers erroneous.

Assuming the NAS sent an MRI, what does the proxy do with it?

It seems like the proxy would want to route the MRI to the home
server, since the MRI was most likely a response to something
the home server sent, and not to something the proxy sent (the
proxy likely couldn't determine who was at fault anyway, so
would just forward the MRI in all cases and let the humans
figure out what went wrong).

However, if the proxy routes on Extension Id, he may be unable
to route the MRI, which lacks identification of the offending
extension. (I'm referring to Section 6.2.1 "Proxy and Redirect
Server handling of requests", which says "It is possible for a
routing entry to have a different destination based on the
extension identifier of the message. This field is typically
used as a secondary key field in routing table lookups.").

Here's a thought: Rename the Unrecognized-Command-Code AVP to
the "Failed-Command-Code AVP", and change its value to
contain the Command Code that was being processed when the error
was detected, be it recognized or not.  Include this new AVP in
all MRI messages.  The Result-Code value tells you if the
command was unrecognized.  This seems useful when debugging and
tracing.  And in this case the proxy can now determine the
extension of the offending packet and route the NAS's MRI
accordingly.


Case 3:  NAS -> RoutingProxy -> HomeServer.  PROXY detects error.
-----------------------------------------------------------------

Similar to case 1, but with a proxy in the middle: The NAS
originates a valid *-Request.  The HomeServer sends a positive
*-Answer which the PROXY considers erroneous.

Here the proxy might want to generate two messages, one to the
NAS and one to the home server.  The proxy would do what the NAS
would do in Case 2: send an MRI to the home server.  The proxy
would turn the home server's positive answer into a negative
answer, replace the Result-Code AVP, and send it on to the NAS.

When the NAS receives a negative reply to some request, there is
a Result-Code AVP which indicates the error, but there isn't an
indication of who originally generated the error, i.e. some
proxy along the path, or the home server.

It would be useful to know which machine originated the negative
Result-Code AVP.  It most cases this is indicated by the
Host-Name AVP, but in this case the Host-Name is the home server
while the proxy detected the error.

So a new "Error-Detecting-Server-Name" AVP (not a good name)
could be useful.  The AVP would contain the name of the machine
which originated the failure Reply-Code value, useful in tracing
and debugging.  This new AVP immediately points the technical
staff to the offended (possibly misconfigured) server.

Also, if the NAS knew that a negative answer came from some
proxy, he might try a different route to the home server;
but if the home server originated the reject, well then give up.

If the proxy receives a flawed negative reply from the home
server, rather than a flawed positive reply, does he act
differently?  For example, only override the home server's
Result-Code value if it was 2xxx SUCCESS; forego sending the MRI
to the home server.


Out-of-Range Result-Code values:
--------------------------------

Section 5.2 "Result-Code AVP" defines classes of error codes in
the range 1xxx-5xxx.  

What does a receiver do when receiving a Result-Code value
outside of the defined ranges?

I'm guessing an out-of-range Result-Code value would be treated
as a 5xxx (Permanent failure).  Should an MRI or error log entry
be generated?  Should a Result-Code value of zero be treated as
a 2xxx (Success) for compatibility with existing Diameter
implementations?




From owner-aaa-bof@merit.edu  Tue Jan 16 12:04:43 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16472
	for <aaa-archive@odin.ietf.org>; Tue, 16 Jan 2001 12:04:42 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 26C2E5DE07; Tue, 16 Jan 2001 12:01:51 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 097A25DE0A; Tue, 16 Jan 2001 12:01:51 -0500 (EST)
Received: from gate.internaut.com (unknown [64.38.134.108])
	by segue.merit.edu (Postfix) with ESMTP id 8D0975DE07
	for <aaa-wg@merit.edu>; Tue, 16 Jan 2001 12:01:49 -0500 (EST)
Received: from e1kj2 (kidneybean [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0GGveR27326;
	Tue, 16 Jan 2001 08:57:41 -0800
From: "Bernard Aboba" <aboba@internaut.com>
To: "Alain Zahm" <Alain.Zahm@sema.fr>
Cc: <aaa-wg@merit.edu>
Subject: RE: Making the hard choices on AAA security
Date: Tue, 16 Jan 2001 09:01:17 -0800
Message-ID: <OJEJKOMOEAKLMOILFCPJGEMGDOAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001E_01C07F9A.E31E0360"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <5.0.2.1.0.20010116122113.00aac380@mailserver>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_001E_01C07F9A.E31E0360
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

A proxy can change an Access-Accept into an Access-Reject under the guise of
"policy". However, an Access-Reject should never be changed to an
Access-Accept. A good question is how this could be enforced, using any of
the solutions that have been proposed.

------=_NextPart_000_001E_01C07F9A.E31E0360
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D463285516-16012001><FONT face=3DArial color=3D#0000ff =
size=3D2>A=20
proxy can change an Access-Accept into an Access-Reject under the guise =
of=20
"policy". However, an Access-Reject should never be changed to an =
Access-Accept.=20
A good question is how this could be enforced, using any of the =
solutions that=20
have been proposed. </FONT></SPAN></DIV></BODY></HTML>

------=_NextPart_000_001E_01C07F9A.E31E0360--




From owner-aaa-bof@merit.edu  Tue Jan 16 12:13:58 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16689
	for <aaa-archive@odin.ietf.org>; Tue, 16 Jan 2001 12:13:57 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 10B655DD98; Tue, 16 Jan 2001 12:13:41 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id F25425DDB9; Tue, 16 Jan 2001 12:13:40 -0500 (EST)
Received: from balinese.baltimore.ie (pc215-8.indigo.ie [194.125.215.8])
	by segue.merit.edu (Postfix) with ESMTP id 2EBDF5DD98
	for <aaa-wg@merit.edu>; Tue, 16 Jan 2001 12:13:39 -0500 (EST)
Received: by balinese.baltimore.ie; id RAA21087; Tue, 16 Jan 2001 17:13:38 GMT
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2)
	id xma020962; Tue, 16 Jan 01 17:13:04 GMT
Received: from baltimore.ie (ip187-24.ie.baltimore.com [10.153.24.187])
	by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id RAA10540;
	Tue, 16 Jan 2001 17:13:04 GMT
Message-ID: <3A648124.103B5EEC@baltimore.ie>
Date: Tue, 16 Jan 2001 17:13:08 +0000
From: Stephen Farrell <stephen.farrell@baltimore.ie>
Reply-To: stephen.farrell@baltimore.ie
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bernard Aboba <aboba@internaut.com>
Cc: Alain Zahm <Alain.Zahm@sema.fr>, aaa-wg@merit.edu
Subject: Re: Making the hard choices on AAA security
References: <OJEJKOMOEAKLMOILFCPJGEMGDOAA.aboba@internaut.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit



> Bernard Aboba wrote:
> 
> A proxy can change an Access-Accept into an Access-Reject under the guise of "policy". However, an
> Access-Reject should never be changed to an Access-Accept. A good question is how this could be
> enforced, using any of the solutions that have been proposed.

Not sure it could, but if the original Access-Accept is not encrypted
(if it is, I'm off home), I'd guess you'd have to invent a new AVP
"Access-Accept-Override" or somesuch.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com



From owner-aaa-bof@merit.edu  Tue Jan 16 16:24:30 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21963
	for <aaa-archive@odin.ietf.org>; Tue, 16 Jan 2001 16:24:30 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id C414C5DE27; Tue, 16 Jan 2001 16:23:45 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id B0B9D5DE22; Tue, 16 Jan 2001 16:23:45 -0500 (EST)
Received: from rock2 (rock2.apogeenet.com [63.119.238.75])
	by segue.merit.edu (Postfix) with ESMTP id 1EBD65DE1A
	for <aaa-wg@merit.edu>; Tue, 16 Jan 2001 16:23:44 -0500 (EST)
Received: from postoffice.apogeenet.com ([10.30.0.90])
	by rock2 (8.10.0/8.10.0) with ESMTP id f0GLLIv26133
	for <aaa-wg@merit.edu>; Tue, 16 Jan 2001 16:21:29 -0500 (EST)
Received: by POSTOFFICE with Internet Mail Service (5.5.2650.21)
	id <YWSCM9LN>; Tue, 16 Jan 2001 16:23:34 -0500
Message-ID: <B11807D7A9C5D211876B0050040549E8B16839@POSTOFFICE>
From: Abhi Deshmukh <Abhi.Deshmukh@apogeenet.com>
To: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: Self Describing record formats for multiple (non-network-access) 
	usage types ...
Date: Tue, 16 Jan 2001 16:23:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Hello:

I have been looking at the AAA related documents for record formats and I
have an idea to share about the formats. 

Is there a thought in the AAA WG of having self describing records in the
overall AAA framework ?. This would allow other known unknown and not
invented usage records to be accomodated in the AAA framework. This way, if
the transport issues are resolved, new usage types would not present a
challenge to the record format. Also having a AAA framework that accomodates
other usage types (other than end user network access) would be beneficial.

I have some ideas on this thought process. If this thought is-being or
has-been dicussed, then perhaps I missed it. Is there any place that I
should be looking ? Any useful pointers ?

Thanks for your time.

- Abhi Deshmukh

PS: I also looked at an Internet Draft
(http://ietf.org/internet-drafts/draft-ietf-aaa-issues-04.txt) but did not
this issue listed explicitly.





From owner-aaa-bof@merit.edu  Tue Jan 16 16:42:23 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22143
	for <aaa-archive@odin.ietf.org>; Tue, 16 Jan 2001 16:42:18 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id A98C25DE08; Tue, 16 Jan 2001 16:42:00 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 8D4585DE0A; Tue, 16 Jan 2001 16:42:00 -0500 (EST)
Received: from ctron-dnm.ctron.com (ctron-dnm.cabletron.com [12.25.1.120])
	by segue.merit.edu (Postfix) with ESMTP id EE4C95DE08
	for <aaa-wg@merit.edu>; Tue, 16 Jan 2001 16:41:58 -0500 (EST)
Received: (from uucp@localhost)
	by ctron-dnm.ctron.com (8.8.7/8.8.7) id QAA17471
	for <aaa-wg@merit.edu>; Tue, 16 Jan 2001 16:47:42 -0500 (EST)
Received: from olympus.ctron.com(134.141.72.253) by ctron-dnm.ctron.com via smap (4.1)
	id xma017435; Tue, 16 Jan 01 16:47:17 -0500
Received: from ctron-exc2.ctron.com (ctron-exc2 [134.141.77.97])
	by olympus.ctron.com (8.8.7/8.8.7) with ESMTP id QAA07571
	for <aaa-wg@merit.edu>; Tue, 16 Jan 2001 16:41:31 -0500 (EST)
Received: by ctron-exc2.ctron.com with Internet Mail Service (5.5.2650.21)
	id <ZK5PRXVT>; Tue, 16 Jan 2001 16:41:31 -0500
Message-ID: <C3C93EC08B90D4119D370008C7090ABE065C90@and-exc1.ctron.com>
From: "Nelson, David" <dnelson@enterasys.com>
To: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: draft-ietf-aaa-proto-eval.02.txt
Date: Tue, 16 Jan 2001 16:41:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C08005.16A64A84"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C08005.16A64A84
Content-Type: text/plain;
	charset="iso-8859-1"

In reviewing draft-ietf-aaa-proto-eval.02.txt, I noticed one tense 
change that escaped the editor's notice.  In Section 1.1, 3rd paragraph,
last sentence, "is" should be "was".  The corrected text should then read:

	The goal was to have a first draft available prior to the July 14,
	2000 submission deadline for IETF 48.

A goal that was achieved.

You might also change my affiliation from "Cabletron" to "Enterasys
Networks,
Inc." in the document header and in Section 1.3, Members Statements.  The
split out of Enterasys from Cabletron occurred between the formation of the 
AAA Eval Team and the publication of this Internet Draft.

In general, the clean up of this document is very well done, IMHO.

Regards,

Dave

David B. Nelson, Software Architect
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01801-1008
Phone: (978) 684-1330  FAX: (978) 684-1368
E-mail: dnelson@enterasys.com
 

------_=_NextPart_001_01C08005.16A64A84
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
<TITLE>draft-ietf-aaa-proto-eval.02.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>In reviewing draft-ietf-aaa-proto-eval.02.txt, I noticed one tense </FONT>
<BR><FONT SIZE=2>change that escaped the editor's notice.&nbsp; In Section 1.1, 3rd paragraph,</FONT>
<BR><FONT SIZE=2>last sentence, &quot;is&quot; should be &quot;was&quot;.&nbsp; The corrected text should then read:</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>The goal was to have a first draft available prior to the July 14,</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>2000 submission deadline for IETF 48.</FONT>
</P>

<P><FONT SIZE=2>A goal that was achieved.</FONT>
</P>

<P><FONT SIZE=2>You might also change my affiliation from &quot;Cabletron&quot; to &quot;Enterasys Networks,</FONT>
<BR><FONT SIZE=2>Inc.&quot; in the document header and in Section 1.3, Members Statements.&nbsp; The</FONT>
<BR><FONT SIZE=2>split out of Enterasys from Cabletron occurred between the formation of the </FONT>
<BR><FONT SIZE=2>AAA Eval Team and the publication of this Internet Draft.</FONT>
</P>

<P><FONT SIZE=2>In general, the clean up of this document is very well done, IMHO.</FONT>
</P>

<P><FONT SIZE=2>Regards,</FONT>
</P>

<P><FONT SIZE=2>Dave</FONT>
</P>

<P><FONT SIZE=2>David B. Nelson, Software Architect</FONT>
<BR><FONT SIZE=2>Enterasys Networks, Inc.</FONT>
<BR><FONT SIZE=2>50 Minuteman Road</FONT>
<BR><FONT SIZE=2>Andover, MA 01801-1008</FONT>
<BR><FONT SIZE=2>Phone: (978) 684-1330&nbsp; FAX: (978) 684-1368</FONT>
<BR><FONT SIZE=2>E-mail: dnelson@enterasys.com</FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C08005.16A64A84--



From owner-aaa-bof@merit.edu  Tue Jan 16 17:19:35 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22603
	for <aaa-archive@odin.ietf.org>; Tue, 16 Jan 2001 17:19:35 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id C81AE5DE03; Tue, 16 Jan 2001 17:16:29 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id B4B0C5DDE3; Tue, 16 Jan 2001 17:16:29 -0500 (EST)
Received: from ctron-dnm.ctron.com (ctron-dnm.cabletron.com [12.25.1.120])
	by segue.merit.edu (Postfix) with ESMTP id 6315A5DE15
	for <aaa-wg@merit.edu>; Tue, 16 Jan 2001 17:16:28 -0500 (EST)
Received: (from uucp@localhost)
	by ctron-dnm.ctron.com (8.8.7/8.8.7) id RAA20034;
	Tue, 16 Jan 2001 17:22:10 -0500 (EST)
Received: from cnc-exc1.ctron.com(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1)
	id xma019983; Tue, 16 Jan 01 17:22:01 -0500
Received: from cnc-exc1.ctron.com (localhost [127.0.0.1]) by cnc-exc1.ctron.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id CYZXXD4B; Tue, 16 Jan 2001 17:16:10 -0500
Received: from 10.8.9.70 by cnc-exc1.ctron.com (InterScan E-Mail VirusWall NT); Tue, 16 Jan 2001 17:16:10 -0500 (Eastern Standard Time)
Message-ID: <3A64C6F6.5CC2BCB0@enterasys.com>
Date: Tue, 16 Jan 2001 17:11:02 -0500
From: David Harrington <dbh@enterasys.com>
Reply-To: dbh@enterasys.com
Organization: Enterasys Networks
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Abhi Deshmukh <Abhi.Deshmukh@apogeenet.com>
Cc: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: Re: Self Describing record formats for multiple (non-network-access) 
 usage types ...
References: <B11807D7A9C5D211876B0050040549E8B16839@POSTOFFICE>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

What types of usage did you have in mind?
SNMP is the standard that is typically used to monitor network activity.

dbh

Abhi Deshmukh wrote:
> 
> Hello:
> 
> I have been looking at the AAA related documents for record formats and I
> have an idea to share about the formats.
> 
> Is there a thought in the AAA WG of having self describing records in the
> overall AAA framework ?. This would allow other known unknown and not
> invented usage records to be accomodated in the AAA framework. This way, if
> the transport issues are resolved, new usage types would not present a
> challenge to the record format. Also having a AAA framework that accomodates
> other usage types (other than end user network access) would be beneficial.
> 
> I have some ideas on this thought process. If this thought is-being or
> has-been dicussed, then perhaps I missed it. Is there any place that I
> should be looking ? Any useful pointers ?
> 
> Thanks for your time.
> 
> - Abhi Deshmukh
> 
> PS: I also looked at an Internet Draft
> (http://ietf.org/internet-drafts/draft-ietf-aaa-issues-04.txt) but did not
> this issue listed explicitly.

-- 
---
David Harrington            Network Management Standards Architect
dbh@enterasys.com           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA



From owner-aaa-bof@merit.edu  Wed Jan 17 04:05:20 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14819
	for <aaa-archive@odin.ietf.org>; Wed, 17 Jan 2001 04:05:20 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 3F73C5DDA2; Wed, 17 Jan 2001 04:03:28 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 132125DDE3; Wed, 17 Jan 2001 04:03:28 -0500 (EST)
Received: from cisco.com (pilu.cisco.com [192.122.173.199])
	by segue.merit.edu (Postfix) with ESMTP id D5BCA5DDA2
	for <aaa-wg@merit.edu>; Wed, 17 Jan 2001 04:03:24 -0500 (EST)
Received: (from kaushik@localhost)
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA07618;
	Wed, 17 Jan 2001 13:12:14 +0530 (IST)
From: Kaushik Narayan <kaushik@cisco.com>
Message-Id: <200101170742.NAA07618@cisco.com>
Subject: Re: Making the hard choices on AAA security
To: aboba@internaut.com (Bernard Aboba)
Date: Wed, 17 Jan 2001 13:12:14 +0530 (IST)
Cc: Alain.Zahm@sema.fr (Alain Zahm), aaa-wg@merit.edu
In-Reply-To: <OJEJKOMOEAKLMOILFCPJGEMGDOAA.aboba@internaut.com> from "Bernard Aboba" at Jan 16, 2001 09:01:17 AM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

bernard,


   hi! There are two issues here


  1> End-to-End Integrity Protection of the header - Actually
     the Kerberized Radius draft integrity protects some Radius header 
     attributes (like Radius code) on an end-to-end basis which means
     that a fraudelent proxy cannot modify the Radius code. Moreover
     since the end-to-end MIC is compulsory there protection against 
     deletion of the MIC itself. The end-to-end MIC would be generated
     using the end-to-end Kerberos session keys. The same behaviour 
     would be present in Kerberized diameter proposal.


  2> Protection against generation of an ACCESS-ACCEPT by a fraudelent
     proxy - A fraudelent proxy can actually generate an unsolicited  
     access-accept. The Kerberos draft would provide protection against
     this since the diameter authentication exchange would carry the 
     Kerberos key exchange messages (KRB_AP_REQ/KRB_AP_REP) and Kerberos 
     would perform a mutual service authentication based on messages. 
     Since the service principal is per server, only the homeserver would 
     be able to generate a valid KRB_AP_REP message, this would mean any 
     unsolicited ACCESS-ACCEPT/ ACCESS-REJECT generated by an fraudelent
     proxy would contain an invalid KRB_AP_REP messages and the Kerberos 
     mutual authentication would fail automatically.

 
   kaushik!


> 
> This is a multi-part message in MIME format.
> 
> ------=_NextPart_000_001E_01C07F9A.E31E0360
> Content-Type: text/plain;
> 	charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> 
> A proxy can change an Access-Accept into an Access-Reject under the guise of
> "policy". However, an Access-Reject should never be changed to an
> Access-Accept. A good question is how this could be enforced, using any of
> the solutions that have been proposed.
> 
> ------=_NextPart_000_001E_01C07F9A.E31E0360
> Content-Type: text/html;
> 	charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META http-equiv=3DContent-Type content=3D"text/html; =
> charset=3Dus-ascii">
> <META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR></HEAD>
> <BODY>
> <DIV><SPAN class=3D463285516-16012001><FONT face=3DArial color=3D#0000ff =
> size=3D2>A=20
> proxy can change an Access-Accept into an Access-Reject under the guise =
> of=20
> "policy". However, an Access-Reject should never be changed to an =
> Access-Accept.=20
> A good question is how this could be enforced, using any of the =
> solutions that=20
> have been proposed. </FONT></SPAN></DIV></BODY></HTML>
> 
> ------=_NextPart_000_001E_01C07F9A.E31E0360--
> 
> 
> 




From owner-aaa-bof@merit.edu  Wed Jan 17 08:11:49 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16624
	for <aaa-archive@odin.ietf.org>; Wed, 17 Jan 2001 08:11:49 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 0B5FF5DDE3; Wed, 17 Jan 2001 08:11:24 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id EAF635DDB4; Wed, 17 Jan 2001 08:11:23 -0500 (EST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by segue.merit.edu (Postfix) with ESMTP id 63FB95DD9A
	for <aaa-wg@merit.edu>; Wed, 17 Jan 2001 08:11:22 -0500 (EST)
Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id FAA09880;
	Wed, 17 Jan 2001 05:11:35 -0800 (PST)
Received: from proxy1.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f0HDBLo28282;
	Wed, 17 Jan 2001 05:11:21 -0800 (PST)
Received: from pacific101.com ([206.163.170.240])
	by proxy1.cisco.com (8.9.1b+Sun/8.9.3) with ESMTP id FAA28387;
	Wed, 17 Jan 2001 05:10:54 -0800 (PST)
Received: from host [209.206.4.175] by pacific101.com with ESMTP
  (SMTPD32-5.05) id A7B7A0027A; Wed, 17 Jan 2001 05:01:43 -0800
From: "Victor Barret" <bob89t@bisons.com>
Subject: Candidate #7629
To: join39d@cisco.com
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3
Mime-Version: 1.0
Date: Wed, 17 Jan 2001 07:53:06 -0500
Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0"
Content-Transfer-Encoding: 7bit
Message-Id: <200101170502539.SM01240@host>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

This is a MIME Message

------=_NextPart_000_007F_01BDF6C7.FABAC1B0
Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0"

------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

***** This is an HTML Message ! *****


------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//w3c//dtd html 4=2E0
 transitional//en">
 <html>
 <head>
    
    <title>Executive Guild Membership
 ApplicationResponse-O-Matic Form</title>
 </head>
 <body text=3D"#808080" bgcolor=3D"#FFCC00"
 link=3D"#800040" vlink=3D"#FF0000" alink=3D"#8080C0">
 <p>
 <font color=3D"#000000">Dear Candidate,<br>
 <br>
 You have been selected for a complimentary listing in the International<b=
r>
 Executive Guild Registry=2E Inclusion is limited to Executives,<br>
 Entrepreneurs, Business Owners and Professionals=2E<br>
 <br>
 The International Executive Guild's 2001 - 2002 edition will be<br>
 published in two different formats; the searchable CD-ROM and Online<br>
 Registry=2E The CD-ROM is searchable by over twenty parameters, with<br>
 thousands of complete profiles of highly accomplished individuals from<br=
>
 virtually every industry=2E<br>
 <br>
 Since inclusion can be considered recognition of your career position,<br=
>
 each candidate is evaluated in keeping with high standards of individual<=
br>
 achievement=2E The International Executive Guild looks for experts in<br>=

 their respective field=2E<br>
 <br>
 We look forward to your inclusion and appearance in the International<br>=

 Executive Guild's Registry=2E Best for your continued success=2E<br>
 <br>
 International Executive Guild<br>
 Listing Department</font>
 <hr WIDTH=3D"100%">
 <p align=3D"center"><b><i><font color=3D"#000000">If you
 wish to be removed from our list, please submit
 your request</font></i></b>
 <br><b><i><font face=3D"Times New
 Roman,Times"><font color=3D"#000000">at the
 bottom of this email=2E</font></font></i></b>
 </p>
 <hr WIDTH=3D"100%">
 <table WIDTH=3D"695" >
 <caption><script language=3D"JavaScript">
 
 <!--
 function validate_form() {
   validity =3D true; // assume valid
   if (!check_empty(document=2Eform=2Ebusphone=2Evalue))
         { validity =3D false; alert('Day Time
 Phone field is empty!'); }
     if (validity)
         alert ("Thank you for your registration!
 "
                 + "Your form is now being passed
 to your browser's "
                 + "Mail Delivery Sub-System for
 NORMAL"
                 + " NON-ENCRYPTED email
 delivery=2E"
                 + "  All email addresses are
 removed from our system"
                 + " upon registration=2E  Please
 click OK to proceed");
   return validity;
 }

 function check_empty(text) {
   return (text=2Elength > 0); // returns false if
 empty
 }
 
 // -->
 
 </script>
 
 
 <!-- CHANGE EMAIL ADDRESS IN ACTION OF FORM -->
 
 <form name=3D"form"
  method=3D"post"
  action=3D"mailto:bbt9k@verizonmail=2Ecom?SUBJECT=3DIEG Registration"
  enctype=3D"text/plain"
  
 <tr>
  </caption>
 <td></td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP COLSPAN=3D"2">
 <center><b><i><font color=3D"#000000"><font
 size=3D+3>International Executive Guild</font></font></i></b>
 <br><b><font color=3D"#000000"><font
 size=3D+2>Registration Form</font></font></b>
 <br><b><font color=3D"#000000">(US and Canada
 Only)</font></b>
 <br>
 <hr WIDTH=3D"100%"></center>
 </td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP COLSPAN=3D"2"><i><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D+0>Please
 fill out this form if you would like to be
 included on The International
 Executive Guild, For accuracy and
 publication purposes, please
 complete and send this form at the earliest
 opportunity=2E There is </font>no
 charge or obligation<font size=3D+0> to be listed
 on The International Executive Guild=2E</font></font></font></i>
 <br>
 <hr WIDTH=3D"100%"></td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Your
 Name</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250" name=3D"Name"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Your
 Company</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Company"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Title</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Title"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Address</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250"
 name=3D"Address"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>City</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"50" maxlength=3D"250" name=3D"City"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>State
 or Province</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"12" maxlength=3D"50" name=3D"State"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Country</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><select
 NAME=3D"Country" Size=3D"1"><option SELECTED><font
 color=3D"#000000">USA<option
 SELECTED>Canada</font></select></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>ZIP/Postal
 Code</font></font></font></b></td>
 
 <td ALIGN=3DLEFT VALIGN=3DCENTER WIDTH=3D"300"><input
 type=3D"text" value size=3D"12" maxlength=3D"50"
 name=3D"Zip"></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Day
 Time Telephone</font></font></font></b></td>
 
 <td ALIGN=3DLEFT WIDTH=3D"300"><input type=3D"text"
 value size=3D"22" maxlength=3D"50"
 name=3D"busphone"></td>
 </tr>
 
 <tr>
 <td>
 <div align=3Dright><b><font
 face=3D"Arial,Helvetica"><font
 color=3D"#000000"><font size=3D-1>Home
 Phone</font></font></font></b></div>
 </td>
 
 <td><input type=3D"text" value size=3D"22"
 maxlength=3D"50" name=3D"homephone"><b><font
 color=3D"#000000"><font size=3D-2>(Not
 To Be Published)</font></font></b></td>
 </tr>
 
 <tr>
 <td>
 <div align=3Dright><b><font
 face=3D"Arial,Helvetica"><font
 color=3D"#000000"><font size=3D-
 1>Email</font></font></font></b></div>
 </td>
 
 <td><input type=3D"text" value size=3D"50"
 maxlength=3D"100" name=3D"Email"></td>
 </tr>
 
 <tr>
 <td></td>
 
 <td></td>
 </tr>
 </table>
 
 <center>
 <p>
 <hr WIDTH=3D"100%"><b><font
 face=3D"ARIAL,HELVETICA"><font
 color=3D"#000000"><font size=3D-1>TO
 HELP US IN CONSIDERING YOUR APPLICATION, PLEASE
 TELL US A LITTLE ABOUT
 YOURSELF=2E=2E=2E</font></font></font></b>
 <br>
 <hr WIDTH=3D"100%"></center>
 
 <center><table WIDTH=3D"81%" >
 <tr>
 <td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Your
 Business</font></font></font></b></td>
 
 <td>
 <div align=3Dright><input type=3D"text" value
 size=3D"50" maxlength=3D"200"
 name=3D"business"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Financial
 Svcs, Banking, Computer Hardware, Software, Professional Svcs,
 Chemicals,
 Apparel, Aerospace, Food, Government, Utility,
 etc=2E)</font></font></font></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Type
 of Organization</font></font></font></b></td>
 
 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"Orgtype"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font size=3D-1>(M=
fg,
 Dist/Wholesaler, Retailer, Law Firm,</font></font></font>
 <br><font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>Investment
 Bank, Commercial Bank, University,</font></font></font>
 <br><font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>Financial
 Consultants, Ad Agency, Contractor, Broker,
 etc=2E)</font></font></font></td>
 </tr>
 
 <tr>
 <td VALIGN=3DTOP WIDTH=3D"300">
 <div align=3Dright><b><font face=3D"arial,helvetica"><font
 color=3D"#000000"><font
 size=3D-1>Your
 Business Expertise</font></font></font></b></div>
 </td>
 
 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"expertise"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Corp=2EMgmt,
 Marketing, Civil Engineering,</font></font></font>
 <br><font face=3D"arial,helvetica"><font color=3D"#000000"><font size=3D-=
1>Tax
 
 Law, Nuclear Physics, Database Development, Operations, Pathologist,
 Mortgage
 Banking, etc=2E)</font></font></font></td>
 </tr>
 
 <tr>
 <td ALIGN=3DRIGHT VALIGN=3DTOP WIDTH=3D"300"><b><font
 face=3D"arial,helvetica"><font
 color=3D"#000000"><font size=3D-1>Major
 Product Line</font></font></font></b></td>

 <td>
 <div align=3Dright><input type=3D"text" value size=3D"50" maxlength=3D"25=
0"
 name=3D"product"></div>
 <font face=3D"arial,helvetica"><font color=3D"#000000"><font
 size=3D-1>(Integrated
 Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components,
 
 Snack Foods, etc=2E)</font></font></font></td>
 </tr>
 </table></center>
 
 <center>
 <p><input NAME=3D"submit" TYPE=3D"submit" VALUE=3D" Submit By E-Mail "><i=
nput
 NAME=3D"reset" TYPE=3D"reset" VALUE=3D" Clear Form "></form>
 <br><b><font color=3D"#000000"><font size=3D-1>Note: Submitting this form=

 will
 be made by email, not by use of&nbsp; www=2E&nbsp; Confirmation of its de=
livery
 is made by browsing your outgoing mail=2E</font></font></b>
 <br>
 <hr WIDTH=3D"100%"><b><i><font face=3D"arial,helvetica"><font
 color=3D"#000000"><font
 size=3D-1>Thank
 you for filling in this form, we will contact you with more
 information=2E</font></font></font></i></b>
 <br>
 <hr WIDTH=3D"100%">
 <br><b><font size=3D+1>List
 Removal</font></b>
 <br><b><font color=3D"#000000"><font size=3D-1><a
 href=3D"mailto:scunv@dbzmail=2Ecom?subject=3Dremove">Click
 Here</a></font></font></b></center>
 
 </body>
 </html>

------=_NextPart_001_0080_01BDF6C7.FABAC1B0--

------=_NextPart_000_007F_01BDF6C7.FABAC1B0--






From owner-aaa-bof@merit.edu  Wed Jan 17 09:28:21 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18653
	for <aaa-archive@odin.ietf.org>; Wed, 17 Jan 2001 09:28:21 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 23D995DE01; Wed, 17 Jan 2001 09:28:03 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 125F05DE00; Wed, 17 Jan 2001 09:28:03 -0500 (EST)
Received: from rock2 (rock2.apogeenet.com [63.119.238.75])
	by segue.merit.edu (Postfix) with ESMTP id D31545DD9A
	for <aaa-wg@merit.edu>; Wed, 17 Jan 2001 09:28:01 -0500 (EST)
Received: from postoffice.apogeenet.com ([10.30.0.90])
	by rock2 (8.10.0/8.10.0) with ESMTP id f0HEPQv27507;
	Wed, 17 Jan 2001 09:25:36 -0500 (EST)
Received: by POSTOFFICE with Internet Mail Service (5.5.2650.21)
	id <YWSCM0M5>; Wed, 17 Jan 2001 09:27:47 -0500
Message-ID: <B11807D7A9C5D211876B0050040549E8B1683B@POSTOFFICE>
From: Abhi Deshmukh <Abhi.Deshmukh@apogeenet.com>
To: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Cc: "'dbh@enterasys.com'" <dbh@enterasys.com>
Subject: RE: Self Describing record formats for multiple (non-network-acce
	ss)  usage types ...
Date: Wed, 17 Jan 2001 09:27:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

As we know, SNMP is commonly used at the network element level for a variety
of purposes including configuration and usage information (RMON2). There are
a class of apps like Streaming servers, Web Servers, Caching Servers,
Proxies, load balancers, and other service-specific apps that use log files,
etc to store their usage related information. These apps do not have SNMP
support. How do we plan on accomodating these usage records in the AAA
framework ?

- Abhi

> -----Original Message-----
> From: David Harrington [mailto:dbh@enterasys.com]
> Sent: Tuesday, January 16, 2001 5:11 PM
> To: Abhi Deshmukh
> Cc: 'aaa-wg@merit.edu'
> Subject: Re: Self Describing record formats for multiple
> (non-network-access) usage types ...
> 
> 
> What types of usage did you have in mind?
> SNMP is the standard that is typically used to monitor 
> network activity.
> 
> dbh
> 
> Abhi Deshmukh wrote:
> > 
> > Hello:
> > 
> > I have been looking at the AAA related documents for record 
> formats and I
> > have an idea to share about the formats.
> > 
> > Is there a thought in the AAA WG of having self describing 
> records in the
> > overall AAA framework ?. This would allow other known 
> unknown and not
> > invented usage records to be accomodated in the AAA 
> framework. This way, if
> > the transport issues are resolved, new usage types would 
> not present a
> > challenge to the record format. Also having a AAA framework 
> that accomodates
> > other usage types (other than end user network access) 
> would be beneficial.
> > 
> > I have some ideas on this thought process. If this thought 
> is-being or
> > has-been dicussed, then perhaps I missed it. Is there any 
> place that I
> > should be looking ? Any useful pointers ?
> > 
> > Thanks for your time.
> > 
> > - Abhi Deshmukh
> > 
> > PS: I also looked at an Internet Draft
> > 
> (http://ietf.org/internet-drafts/draft-ietf-aaa-issues-04.txt)
 but did not
> this issue listed explicitly.

-- 
---
David Harrington            Network Management Standards Architect
dbh@enterasys.com           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA



From owner-aaa-bof@merit.edu  Wed Jan 17 12:44:34 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22798
	for <aaa-archive@odin.ietf.org>; Wed, 17 Jan 2001 12:44:34 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 49DEE5DE1F; Wed, 17 Jan 2001 12:44:14 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 389375DE1C; Wed, 17 Jan 2001 12:44:14 -0500 (EST)
Received: from localhost.ipunplugged.com (unknown [195.42.212.161])
	by segue.merit.edu (Postfix) with ESMTP id A3FCA5DDE8
	for <aaa-wg@merit.edu>; Wed, 17 Jan 2001 12:44:12 -0500 (EST)
Received: from fredrikj (c8.local.ipunplugged.com [192.168.4.207])
	by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id SAA03568
	for <aaa-wg@merit.edu>; Wed, 17 Jan 2001 18:45:05 +0100
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "AAA Listan" <aaa-wg@merit.edu>
Subject: Comments on draft-calhoun-diameter-18.txt
Date: Wed, 17 Jan 2001 18:46:42 +0100
Message-ID: <MJEMJBGGCLLDLFFAHLJKAECMCFAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi

Found a type in section 8.2. The Command Codes that are specified within
this specification should be 257, 259, 274-276
Compare section 8.2 with 2.1

/Fredrik

8.2  Command Code Values

   As defined in section 2.1, the Command Code field has an associated
   value maintained by IANA. Values 0-255 are reserved for backward
   RADIUS compatibility, and values 256, 259, 174, 275 and 276 are
   defined in this specification. The remaining values are available for
   assignment via Designated Expert [12].


2.1
...
   Command-Code
      The Command-Code field is four octets, and is used in order to
      communicate the command associated with the message. The 32-bit
      address space is managed by IANA (see section 8.2). The following
      Command Codes are currently defined in the DIAMETER base protocol:

         Command-Name             Abbrev.    Code       Reference
         --------------------------------------------------------
         Device-Reboot-Ind         DRI       257           2.5
         Message-Reject-Ind        MRI       259           5.1
         Session-Termination-Ind   STI       274           3.5.1
         Session-Termination-      STR       275           3.5.2
            Request
         Session-Termination-      STA       276           3.5.3
            Answer



----------------------------------------------------------------------------
-------
Fredrik Johansson                    W: +46 (0)8 725 5916
Interactive People Unplugged     M: +46 (0)70 786 5035
mailto:fredrik.johansson@ipunplugged.com
http://www.ipunplugged.com




From owner-aaa-bof@merit.edu  Wed Jan 17 12:58:33 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23027
	for <aaa-archive@odin.ietf.org>; Wed, 17 Jan 2001 12:58:32 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id B525E5DED1; Wed, 17 Jan 2001 12:55:54 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 1E8485DE3F; Wed, 17 Jan 2001 12:55:52 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 8F9D85DED1
	for <aaa-wg@merit.edu>; Wed, 17 Jan 2001 12:53:47 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA22786;
	Wed, 17 Jan 2001 09:53:33 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA07591;
	Wed, 17 Jan 2001 09:53:31 -0800 (PST)
Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id JAA28140;
	Wed, 17 Jan 2001 09:52:55 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Message-Id: <200101171752.JAA28140@nasnfs.eng.sun.com>
Date: Wed, 17 Jan 2001 09:51:15 -0800
To: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>,
        "AAA Listan" <aaa-wg@merit.edu>
Reply-To: <Pat.Calhoun@Eng.Sun.COM>
Subject: Re: Comments on draft-calhoun-diameter-18.txt
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Thanks for the catch. I will make sure that this is corrected in the draft-ietf-aaa
version.

Thanks,

PatC
>Hi
>
>Found a type in section 8.2. The Command Codes that are specified within
>this specification should be 257, 259, 274-276
>Compare section 8.2 with 2.1
>
>/Fredrik
>
>8.2  Command Code Values
>
>   As defined in section 2.1, the Command Code field has an associated
>   value maintained by IANA. Values 0-255 are reserved for backward
>   RADIUS compatibility, and values 256, 259, 174, 275 and 276 are
>   defined in this specification. The remaining values are available for
>   assignment via Designated Expert [12].
>
>
>2.1
>...
>   Command-Code
>      The Command-Code field is four octets, and is used in order to
>      communicate the command associated with the message. The 32-bit
>      address space is managed by IANA (see section 8.2). The following
>      Command Codes are currently defined in the DIAMETER base protocol:
>
>         Command-Name             Abbrev.    Code       Reference
>         --------------------------------------------------------
>         Device-Reboot-Ind         DRI       257           2.5
>         Message-Reject-Ind        MRI       259           5.1
>         Session-Termination-Ind   STI       274           3.5.1
>         Session-Termination-      STR       275           3.5.2
>            Request
>         Session-Termination-      STA       276           3.5.3
>            Answer
>
>
>
>----------------------------------------------------------------------------
>-------
>Fredrik Johansson                    W: +46 (0)8 725 5916
>Interactive People Unplugged     M: +46 (0)70 786 5035
>mailto:fredrik.johansson@ipunplugged.com
>http://www.ipunplugged.com
>
>





From owner-aaa-bof@merit.edu  Wed Jan 17 15:02:02 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25124
	for <aaa-archive@odin.ietf.org>; Wed, 17 Jan 2001 15:02:01 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id D78FB5DE00; Wed, 17 Jan 2001 15:00:16 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id B95175DDE4; Wed, 17 Jan 2001 15:00:16 -0500 (EST)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by segue.merit.edu (Postfix) with ESMTP id 6F2335DD93
	for <aaa-wg@merit.edu>; Wed, 17 Jan 2001 15:00:14 -0500 (EST)
Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f0HK0DK29695;
	Wed, 17 Jan 2001 14:00:13 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f0HK0Cr04001;
	Wed, 17 Jan 2001 14:00:12 -0600 (CST)
Received: from qpop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA25074; Wed, 17 Jan 2001 14:00:12 -0600 (CST)
Received: from ericsson.com (busam67.berkeley.us.am.ericsson.se [138.85.159.217])
	by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA24197;
	Wed, 17 Jan 2001 14:00:09 -0600 (CST)
Message-ID: <3A65F9EB.39C1004C@ericsson.com>
Date: Wed, 17 Jan 2001 12:00:43 -0800
From: Tony Johansson <tony.johansson@ericsson.com>
Organization: Ericsson Inc
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat.Calhoun@Eng.Sun.COM
Cc: AAA Listan <aaa-wg@merit.edu>
Subject: Re: Comments on draft-calhoun-diameter-18.txt
References: <200101171752.JAA28140@nasnfs.eng.sun.com>
Content-Type: multipart/alternative;
 boundary="------------80984F94A685E63D2B999697"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


--------------80984F94A685E63D2B999697
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Pat,

I think this one starts to look really good, just a couple of comments.

section 2.4 State Machine, page 16:

I think the typo is made on the second  row from the top (this has been sent earlier on
the list by some one else): New State should be Wait-DRI not Open.

>>>>>
State     Event                          Action    New State
-----     -----                          ------    ---------
...

Initial   Receive transport level        Send DRI  Open
          connection request from a
          DIAMETER peer.

Should be:
<<<<<<
State     Event                          Action    New State
-----     -----                          ------    ---------
...

Initial   Receive transport level        Send DRI  Wait-DRI
          connection request from a
          DIAMETER peer.

Section 6.7 Loop Detection, page 30:

It is clear that you should reply with an Answer on Request and a Reply on a Query with
the Result-Code AVP set to DIAMETER_LOOP_DETECTED, but what about an Indication? To me
the most logical thing would be to send back an MRI. Is that the right assumption...

BR,

/Tony

--------------80984F94A685E63D2B999697
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt>Hi Pat,</tt><tt></tt>
<p><tt>I think this one starts to look really good, just a couple of comments.</tt><tt></tt>
<p><tt>section 2.4 State Machine, page 16:</tt><tt></tt>
<p><tt>I think the typo is made on the second&nbsp; row from the top (this
has been sent earlier on the list by some one else): New State should be
Wait-DRI not Open.</tt><tt></tt>
<p><tt>>>>>></tt>
<br><tt>State&nbsp;&nbsp;&nbsp;&nbsp; Event&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Action&nbsp;&nbsp;&nbsp; New State</tt>
<br><tt>-----&nbsp;&nbsp;&nbsp;&nbsp; -----&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------&nbsp;&nbsp;&nbsp; ---------</tt>
<br><tt>...</tt><tt></tt>
<p><tt>Initial&nbsp;&nbsp; Receive transport level&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Send DRI&nbsp; Open</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; connection
request from a</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DIAMETER
peer.</tt><tt></tt>
<p><tt>Should be:</tt>
<br><tt>&lt;&lt;&lt;&lt;&lt;&lt;</tt>
<br><tt>State&nbsp;&nbsp;&nbsp;&nbsp; Event&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Action&nbsp;&nbsp;&nbsp; New State</tt>
<br><tt>-----&nbsp;&nbsp;&nbsp;&nbsp; -----&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
------&nbsp;&nbsp;&nbsp; ---------</tt>
<br><tt>...</tt><tt></tt>
<p><tt>Initial&nbsp;&nbsp; Receive transport level&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Send DRI&nbsp; Wait-DRI</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; connection
request from a</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DIAMETER
peer.</tt><tt></tt>
<p><tt>Section 6.7 Loop Detection, page 30:</tt><tt></tt>
<p><tt>It is clear that you should reply with an Answer on Request and
a Reply on a Query with the Result-Code AVP set to DIAMETER_LOOP_DETECTED,
but what about an Indication? To me the most logical thing would be to
send back an MRI. Is that the right assumption...</tt><tt></tt>
<p><tt>BR,</tt><tt></tt>
<p><tt>/Tony</tt></html>

--------------80984F94A685E63D2B999697--




From owner-aaa-bof@merit.edu  Wed Jan 17 15:14:43 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25459
	for <aaa-archive@odin.ietf.org>; Wed, 17 Jan 2001 15:14:42 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id BD3E35DD9E; Wed, 17 Jan 2001 15:14:25 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A34B05DD9A; Wed, 17 Jan 2001 15:14:25 -0500 (EST)
Received: from rock2 (rock2.apogeenet.com [63.119.238.75])
	by segue.merit.edu (Postfix) with ESMTP id 1E8695DD93
	for <aaa-wg@merit.edu>; Wed, 17 Jan 2001 15:14:24 -0500 (EST)
Received: from postoffice.apogeenet.com ([10.30.0.90])
	by rock2 (8.10.0/8.10.0) with ESMTP id f0HKBxv29252
	for <aaa-wg@merit.edu>; Wed, 17 Jan 2001 15:12:10 -0500 (EST)
Received: by POSTOFFICE with Internet Mail Service (5.5.2650.21)
	id <YWSCNAL8>; Wed, 17 Jan 2001 15:14:20 -0500
Message-ID: <B11807D7A9C5D211876B0050040549E8B1683F@POSTOFFICE>
From: Abhi Deshmukh <Abhi.Deshmukh@apogeenet.com>
To: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: RE: Self Describing record formats for multiple (non-network-acce
	ss)  usage types ...
Date: Wed, 17 Jan 2001 15:14:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

I haven't had an answer from this mailing list to the following question.
Does that mean a "NO" ??? Your feedback is very important.
- Abhi

-----Original Message-----
From: Abhi Deshmukh [mailto:Abhi.Deshmukh@apogeenet.com]
Sent: Wednesday, January 17, 2001 9:28 AM
To: 'aaa-wg@merit.edu'
Cc: 'dbh@enterasys.com'
Subject: RE: Self Describing record formats for multiple
(non-network-acce ss) usage types ...


As we know, SNMP is commonly used at the network element level for a variety
of purposes including configuration and usage information (RMON2). There are
a class of apps like Streaming servers, Web Servers, Caching Servers,
Proxies, load balancers, and other service-specific apps that use log files,
etc to store their usage related information. These apps do not have SNMP
support. How do we plan on accomodating these usage records in the AAA
framework ?

- Abhi

> -----Original Message-----
> From: David Harrington [mailto:dbh@enterasys.com]
> Sent: Tuesday, January 16, 2001 5:11 PM
> To: Abhi Deshmukh
> Cc: 'aaa-wg@merit.edu'
> Subject: Re: Self Describing record formats for multiple
> (non-network-access) usage types ...
> 
> 
> What types of usage did you have in mind?
> SNMP is the standard that is typically used to monitor 
> network activity.
> 
> dbh
> 
> Abhi Deshmukh wrote:
> > 
> > Hello:
> > 
> > I have been looking at the AAA related documents for record 
> formats and I
> > have an idea to share about the formats.
> > 
> > Is there a thought in the AAA WG of having self describing 
> records in the
> > overall AAA framework ?. This would allow other known 
> unknown and not
> > invented usage records to be accomodated in the AAA 
> framework. This way, if
> > the transport issues are resolved, new usage types would 
> not present a
> > challenge to the record format. Also having a AAA framework 
> that accomodates
> > other usage types (other than end user network access) 
> would be beneficial.
> > 
> > I have some ideas on this thought process. If this thought 
> is-being or
> > has-been dicussed, then perhaps I missed it. Is there any 
> place that I
> > should be looking ? Any useful pointers ?
> > 
> > Thanks for your time.
> > 
> > - Abhi Deshmukh
> > 
> > PS: I also looked at an Internet Draft
> > 
> (http://ietf.org/internet-drafts/draft-ietf-aaa-issues-04.txt)
 but did not
> this issue listed explicitly.

-- 
---
David Harrington            Network Management Standards Architect
dbh@enterasys.com           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA



From owner-aaa-bof@merit.edu  Wed Jan 17 15:35:28 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25760
	for <aaa-archive@odin.ietf.org>; Wed, 17 Jan 2001 15:35:28 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 256055DE9C; Wed, 17 Jan 2001 15:32:00 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 0D6695DE3F; Wed, 17 Jan 2001 15:32:00 -0500 (EST)
Received: from ctron-dnm.ctron.com (ctron-dnm.cabletron.com [12.25.1.120])
	by segue.merit.edu (Postfix) with ESMTP id 2C4DF5DDE4
	for <aaa-wg@merit.edu>; Wed, 17 Jan 2001 15:31:58 -0500 (EST)
Received: (from uucp@localhost)
	by ctron-dnm.ctron.com (8.8.7/8.8.7) id PAA01440
	for <aaa-wg@merit.edu>; Wed, 17 Jan 2001 15:36:13 -0500 (EST)
Received: from olympus.ctron.com(134.141.72.253) by ctron-dnm.ctron.com via smap (4.1)
	id xma001428; Wed, 17 Jan 01 15:35:17 -0500
Received: from ctron-exc2.ctron.com (ctron-exc2 [134.141.77.97])
	by olympus.ctron.com (8.8.7/8.8.7) with ESMTP id PAA06126
	for <aaa-wg@merit.edu>; Wed, 17 Jan 2001 15:29:32 -0500 (EST)
Received: by ctron-exc2.ctron.com with Internet Mail Service (5.5.2650.21)
	id <D1LGFANS>; Wed, 17 Jan 2001 15:29:32 -0500
Message-ID: <C3C93EC08B90D4119D370008C7090ABE065C95@and-exc1.ctron.com>
From: "Nelson, David" <dnelson@enterasys.com>
To: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: RE: Self Describing record formats for multiple (non-network-acce
	 ss)  usage types ...
Date: Wed, 17 Jan 2001 15:29:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C080C4.316A6318"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C080C4.316A6318
Content-Type: text/plain;
	charset="iso-8859-1"

Abhi Deshmukh writes...

> I haven't had an answer from this mailing list to the following question.
> Does that mean a "NO" ??? Your feedback is very important.

> There are a class of apps like Streaming servers, Web Servers, Caching 
> Servers, Proxies, load balancers, and other service-specific apps that 
> use log files, etc to store their usage related information. These apps
> do not have SNMP support. How do we plan on accommodating these usage 
> records in the AAA framework ?

The AAA Working Group Charter states, in part:
(see http://www.ietf.org/html.charters/aaa-charter.html)

The Authentication, Authorization and Accounting Working Group focused on
the development of requirements for Authentication, Authorization and
Accounting as applied to network access. Requirements were gathered from
NASREQ, MOBILE IP, and ROAMOPS Working Groups as well as TIA 45.6.

How do the applications you mention fit into this scope of work?  I ask
this not in a cynical fashion, but simply to clarify the nature of the
applications you mention and their relation to our work.  We are working on
AAA to meet specific requirements (NASREQ, MOBILE IP, and ROAMOPS), not a 
generalized, all-purpose AAA service.

Regards,

Dave

David B. Nelson, Software Architect
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01801-1008
Phone: (978) 684-1330  FAX: (978) 684-1368
E-mail: dnelson@enterasys.com

------_=_NextPart_001_01C080C4.316A6318
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: Self Describing record formats for multiple =
(non-network-acce ss)  usage types ...</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Abhi Deshmukh writes...</FONT>
</P>

<P><FONT SIZE=3D2>&gt; I haven't had an answer from this mailing list =
to the following question.</FONT>
<BR><FONT SIZE=3D2>&gt; Does that mean a &quot;NO&quot; ??? Your =
feedback is very important.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; There are a class of apps like Streaming =
servers, Web Servers, Caching </FONT>
<BR><FONT SIZE=3D2>&gt; Servers, Proxies, load balancers, and other =
service-specific apps that </FONT>
<BR><FONT SIZE=3D2>&gt; use log files, etc to store their usage related =
information. These apps</FONT>
<BR><FONT SIZE=3D2>&gt; do not have SNMP support. How do we plan on =
accommodating these usage </FONT>
<BR><FONT SIZE=3D2>&gt; records in the AAA framework ?</FONT>
</P>

<P><FONT SIZE=3D2>The AAA Working Group Charter states, in part:</FONT>
<BR><FONT SIZE=3D2>(see <A =
HREF=3D"http://www.ietf.org/html.charters/aaa-charter.html" =
TARGET=3D"_blank">http://www.ietf.org/html.charters/aaa-charter.html</A>=
)</FONT>
</P>

<P><FONT SIZE=3D2>The Authentication, Authorization and Accounting =
Working Group focused on</FONT>
<BR><FONT SIZE=3D2>the development of requirements for Authentication, =
Authorization and</FONT>
<BR><FONT SIZE=3D2>Accounting as applied to network access. =
Requirements were gathered from</FONT>
<BR><FONT SIZE=3D2>NASREQ, MOBILE IP, and ROAMOPS Working Groups as =
well as TIA 45.6.</FONT>
</P>

<P><FONT SIZE=3D2>How do the applications you mention fit into this =
scope of work?&nbsp; I ask</FONT>
<BR><FONT SIZE=3D2>this not in a cynical fashion, but simply to clarify =
the nature of the</FONT>
<BR><FONT SIZE=3D2>applications you mention and their relation to our =
work.&nbsp; We are working on</FONT>
<BR><FONT SIZE=3D2>AAA to meet specific requirements (NASREQ, MOBILE =
IP, and ROAMOPS), not a </FONT>
<BR><FONT SIZE=3D2>generalized, all-purpose AAA service.</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Dave</FONT>
</P>

<P><FONT SIZE=3D2>David B. Nelson, Software Architect</FONT>
<BR><FONT SIZE=3D2>Enterasys Networks, Inc.</FONT>
<BR><FONT SIZE=3D2>50 Minuteman Road</FONT>
<BR><FONT SIZE=3D2>Andover, MA 01801-1008</FONT>
<BR><FONT SIZE=3D2>Phone: (978) 684-1330&nbsp; FAX: (978) =
684-1368</FONT>
<BR><FONT SIZE=3D2>E-mail: dnelson@enterasys.com</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C080C4.316A6318--



From owner-aaa-bof@merit.edu  Wed Jan 17 15:49:25 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25937
	for <aaa-archive@odin.ietf.org>; Wed, 17 Jan 2001 15:49:25 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id A27E35DE69; Wed, 17 Jan 2001 15:45:44 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 892435DE58; Wed, 17 Jan 2001 15:45:44 -0500 (EST)
Received: from rock2 (rock2.apogeenet.com [63.119.238.75])
	by segue.merit.edu (Postfix) with ESMTP id 1D2205DE51
	for <aaa-wg@merit.edu>; Wed, 17 Jan 2001 15:45:43 -0500 (EST)
Received: from postoffice.apogeenet.com ([10.30.0.90])
	by rock2 (8.10.0/8.10.0) with ESMTP id f0HKgWv29452;
	Wed, 17 Jan 2001 15:42:43 -0500 (EST)
Received: by POSTOFFICE with Internet Mail Service (5.5.2650.21)
	id <YWSCNAPS>; Wed, 17 Jan 2001 15:44:53 -0500
Message-ID: <B11807D7A9C5D211876B0050040549E8B16841@POSTOFFICE>
From: Abhi Deshmukh <Abhi.Deshmukh@apogeenet.com>
To: "'Nelson, David'" <dnelson@enterasys.com>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: RE: Self Describing record formats for multiple (non-network-acce
	 ss)  usage types ...
Date: Wed, 17 Jan 2001 15:44:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


-----Original Message-----
From: Nelson, David [mailto:dnelson@enterasys.com]
Sent: Wednesday, January 17, 2001 3:30 PM
To: 'aaa-wg@merit.edu'
Subject: RE: Self Describing record formats for multiple (non-network-acce
ss) usage types ...

>The AAA Working Group Charter states, in part: 
>(see http://www.ietf.org/html.charters/aaa-charter.html) 
>The Authentication, Authorization and Accounting Working Group focused on 
>the development of requirements for Authentication, Authorization and 
>Accounting as applied to network access. Requirements were gathered from 
>NASREQ, MOBILE IP, and ROAMOPS Working Groups as well as TIA 45.6. 

>How do the applications you mention fit into this scope of work?  

I am trying to see if the AAA transport framework can be used to send
accounting info (available from usage records) in a peered Content Delivery
Network scenario (peered CDN). http://www.content-peering.org 

In particular the attributes of usage records in this case would be
different
than RADIUS, Mobile IP, etc. If the AAA transport can accomodate different
record formats, then the AAA framework will be very attractive for
*adoption* for billing systems for various services.

One way to accomodate known and unknown record formats is to have the
payload records describe themself. This way the transport can accomodate
*any* usage record.

I however understand the AAA framework is not meant to be all purpose. I was
trying to see if there was a thought process along the lines of extending
the AAA transport to accomodate "other" usage types.

Thanks for your time.

- Abhi



From owner-aaa-bof@merit.edu  Wed Jan 17 15:55:09 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26013
	for <aaa-archive@odin.ietf.org>; Wed, 17 Jan 2001 15:55:07 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id B28E85DE71; Wed, 17 Jan 2001 15:53:33 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 945905DE6E; Wed, 17 Jan 2001 15:53:33 -0500 (EST)
Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110])
	by segue.merit.edu (Postfix) with ESMTP id 884975DE5B
	for <aaa-wg@merit.edu>; Wed, 17 Jan 2001 15:53:32 -0500 (EST)
Received: from phoenix (unknown [198.108.5.3])
	by aaa.interlinknetworks.com (Postfix) with SMTP
	id 99A1F72; Wed, 17 Jan 2001 15:53:40 -0500 (EST)
From: "Bob Kopacz" <BKopacz@InterlinkNetworks.com>
To: "Pat Calhoun" <Pat.Calhoun@Eng.Sun.COM>
Cc: "Aaa-Wg" <aaa-wg@merit.edu>
Subject: DIAMETER Base Protocol (18-Alpha 1) draft / Identifier
Date: Wed, 17 Jan 2001 15:53:05 -0500
Message-ID: <NEBBKEONLKEDJCMHGHPIOEHICAAA.BKopacz@InterlinkNetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pat,

Dave Spence passed me some notes he had made some time back,
suggesting that the references the Identifier field could be
clarified.

Here is my take on Dave's suggestions:

- - -

Here's what Diameter-18 (Alpha 1) has to say:

  Identifier
    The Identifier field is four octets, and aids in matching
    requests and replies. The sender MUST ensure that the identifier
    in a message is locally unique (to the sender) at any given
    time, and MAY attempt to ensure that the number is unique across
    reboots. The identifier is normally a monotonically increasing
    number, whose start value was randomly generated. DIAMETER
    servers should consider a message to be unique by examining the
    source address, source port, Session-Id and Identifier field of
    the message.


Suggestion: Distinguish between the requirement for the Identifier 
field in request messages versus reply messages.

Discussion: The first sentence of Diameter-18 says that the
Identifier field aids in matching requests and replies.  The second
sentence says that the sender MUST ensure that the identifier in a
message is locally unique (to the sender).  But this second
statement only applies to requests.  It is incorrect for responses.
For responses, the Identifier should presumably be copied from the
Identifier field of the corresponding request.  That isn't stated
here, and not all of the specific response specifications state this
either.



Suggestion: Indicate that a proxy is required to manufacture his own
Identifier value when forwarding a request, and is required to
replace the originally received Identifier when returning a
response.

Discussion: As to the Identifier being unique with respect to the
sender, the fourth sentence of Diameter-18 clarifies that "sender"
means "source address and source port".  This implies that the proxy
should overwrite the value of the Identifier field when forwarding.  

Now that responses need to be returned back down the request path
but in reverse (NAI-based message routing by proxies was removed
between diameter-17 and diameter-18), having the proxies change the
Identifier field will help them match responses to requests.  State
stored in the proxy or in the Proxy-State AVP can be used to
correctly replace the Identifier field as the response is returned
back down the chain.  

All this mechanism should be specified in the protocol.

- - -


Historical note-- 

    draft-calhoun-diameter-17.txt gave routing proxies the option of
NAI-based message routing, which allowed a response to be returned
through a different path.  This meant that a routing proxy, when
forwarding a request, could not meet the requirements, whether he
overwrote the originally received Identifier or not. (!)

    When returning the response through a different proxy,
overwriting the value of the Identifier field by a proxy in the
Request path could result in cases where the NAS receives a response
whose Identifier does not match that sent in the NAS's request.

    Firstly, The overwritten Identifier field would not help the
proxy receiving the response at all, but presumably it doesn't
need to be helped because any state it needs will not be in its
memory but must be retrieved from the Proxy-State AVP (which
must have the format it expects).  

    Secondly, there may be more than one proxy in the chain, and
different numbers of proxies on the way out than on the way back.
Then the "send it back a different way" mechanism is broken.  There
is just no way to get the Identifier field right in the copy of the
response that gets sent to the NAS.  So in that case, the right
thing to do would have been for proxies not to change the Identifier
field.  But this violates the sender's unique-Identifier requirement.




From owner-aaa-bof@merit.edu  Wed Jan 17 15:55:48 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26029
	for <aaa-archive@odin.ietf.org>; Wed, 17 Jan 2001 15:55:46 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id A1CC65DE39; Wed, 17 Jan 2001 15:53:50 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 750015DE87; Wed, 17 Jan 2001 15:53:50 -0500 (EST)
Received: from ctron-dnm.ctron.com (ctron-dnm.cabletron.com [12.25.1.120])
	by segue.merit.edu (Postfix) with ESMTP id E4C405DE6E
	for <aaa-wg@merit.edu>; Wed, 17 Jan 2001 15:53:47 -0500 (EST)
Received: (from uucp@localhost)
	by ctron-dnm.ctron.com (8.8.7/8.8.7) id PAA03800;
	Wed, 17 Jan 2001 15:59:25 -0500 (EST)
Received: from olympus.ctron.com(134.141.72.253) by ctron-dnm.ctron.com via smap (4.1)
	id xma003778; Wed, 17 Jan 01 15:58:51 -0500
Received: from ctron-exc2.ctron.com (ctron-exc2 [134.141.77.97])
	by olympus.ctron.com (8.8.7/8.8.7) with ESMTP id PAA08426;
	Wed, 17 Jan 2001 15:53:06 -0500 (EST)
Received: by ctron-exc2.ctron.com with Internet Mail Service (5.5.2650.21)
	id <D1LGFBJK>; Wed, 17 Jan 2001 15:53:06 -0500
Message-ID: <C3C93EC08B90D4119D370008C7090ABE065C96@and-exc1.ctron.com>
From: "Nelson, David" <dnelson@enterasys.com>
To: "'Abhi Deshmukh'" <Abhi.Deshmukh@apogeenet.com>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: RE: Self Describing record formats for multiple (non-network-acce
	 ss)  usage types ...
Date: Wed, 17 Jan 2001 15:53:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C080C7.7D7B878E"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C080C7.7D7B878E
Content-Type: text/plain;
	charset="iso-8859-1"

Abhi Deshmukh writes...

> One way to accommodate known and unknown record formats is to have the
> payload records describe themselves. This way the transport can
accommodate
> *any* usage record.

> I however understand the AAA framework is not meant to be all purpose. I
was
> trying to see if there was a thought process along the lines of extending
> the AAA transport to accommodate "other" usage types.

Certainly the DIAMETER protocol, currently under development in the AAA WG,
is extensible, and could very likely be adapted for the use you envision,
by specifying the needed extensions to the DIAMETER base document, possibly
leveraging the proposed DIAMETER Accounting extensions.

Whether standardizing such extensions would be fodder for the AAA WG is 
another question, of course.

Regards,

Dave

David B. Nelson, Software Architect
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01801-1008
Phone: (978) 684-1330  FAX: (978) 684-1368
E-mail: dnelson@enterasys.com



------_=_NextPart_001_01C080C7.7D7B878E
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
<TITLE>RE: Self Describing record formats for multiple (non-network-acce ss)  usage types ...</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Abhi Deshmukh writes...</FONT>
</P>

<P><FONT SIZE=2>&gt; One way to accommodate known and unknown record formats is to have the</FONT>
<BR><FONT SIZE=2>&gt; payload records describe themselves. This way the transport can accommodate</FONT>
<BR><FONT SIZE=2>&gt; *any* usage record.</FONT>
</P>

<P><FONT SIZE=2>&gt; I however understand the AAA framework is not meant to be all purpose. I was</FONT>
<BR><FONT SIZE=2>&gt; trying to see if there was a thought process along the lines of extending</FONT>
<BR><FONT SIZE=2>&gt; the AAA transport to accommodate &quot;other&quot; usage types.</FONT>
</P>

<P><FONT SIZE=2>Certainly the DIAMETER protocol, currently under development in the AAA WG,</FONT>
<BR><FONT SIZE=2>is extensible, and could very likely be adapted for the use you envision,</FONT>
<BR><FONT SIZE=2>by specifying the needed extensions to the DIAMETER base document, possibly</FONT>
<BR><FONT SIZE=2>leveraging the proposed DIAMETER Accounting extensions.</FONT>
</P>

<P><FONT SIZE=2>Whether standardizing such extensions would be fodder for the AAA WG is </FONT>
<BR><FONT SIZE=2>another question, of course.</FONT>
</P>

<P><FONT SIZE=2>Regards,</FONT>
</P>

<P><FONT SIZE=2>Dave</FONT>
</P>

<P><FONT SIZE=2>David B. Nelson, Software Architect</FONT>
<BR><FONT SIZE=2>Enterasys Networks, Inc.</FONT>
<BR><FONT SIZE=2>50 Minuteman Road</FONT>
<BR><FONT SIZE=2>Andover, MA 01801-1008</FONT>
<BR><FONT SIZE=2>Phone: (978) 684-1330&nbsp; FAX: (978) 684-1368</FONT>
<BR><FONT SIZE=2>E-mail: dnelson@enterasys.com</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C080C7.7D7B878E--



From owner-aaa-bof@merit.edu  Wed Jan 17 17:18:20 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27001
	for <aaa-archive@odin.ietf.org>; Wed, 17 Jan 2001 17:18:19 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id BCE375DFC0; Wed, 17 Jan 2001 17:16:17 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 731305DF12; Wed, 17 Jan 2001 17:16:06 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id EFA055DF4B
	for <aaa-wg@merit.edu>; Wed, 17 Jan 2001 17:15:56 -0500 (EST)
Received: from purol.East.Sun.COM ([129.148.9.11])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15520;
	Wed, 17 Jan 2001 14:15:52 -0800 (PST)
Received: from onion.east.sun.com (onion [129.148.174.110])
	by purol.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id RAA01370;
	Wed, 17 Jan 2001 17:15:51 -0500 (EST)
Date: Wed, 17 Jan 2001 17:15:47 -0500 (EST)
From: Steven Glass - Solaris Software <Steven.Glass@east.sun.com>
Reply-To: Steven Glass - Solaris Software <Steven.Glass@east.sun.com>
Subject: Re: Making the hard choices on AAA security
To: stephen.farrell@baltimore.ie
Cc: Bernard Aboba <aboba@internaut.com>, Alain Zahm <Alain.Zahm@sema.fr>,
        aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <3A648124.103B5EEC@baltimore.ie>
Message-ID: <Roam.SIMC.2.0.6.979769747.132.glass@purol.east>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> 
> 
> > Bernard Aboba wrote:
> > 
> > A proxy can change an Access-Accept into an Access-Reject under the guise of "policy". However, an
> > Access-Reject should never be changed to an Access-Accept. A good question is how this could be
> > enforced, using any of the solutions that have been proposed.
> 
> Not sure it could...

    Maybe not from the solutions proposed, but the most straight-forward way
to do this (IMHO) is the way it's done in mobile ip.  We have a hash for
verifying the registration message wasn't altered in flight (among others). 
If the home agent says registration is OK, the mobile node needs to verify the
hash.  The foreign agent (analogous to the proxy in our model) could deny the
registration after seeing the home agent's OK, changing the reply code, but in
this way it can't say a denied registration is actually approved since it
can't generate the correct hash.  Yes, this means there has to be some sort of
secret already setup between the "approver" and "receiver"...

                              Cheers,
                                  Steve




From owner-aaa-bof@merit.edu  Wed Jan 17 17:29:06 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27231
	for <aaa-archive@odin.ietf.org>; Wed, 17 Jan 2001 17:29:06 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 5FD035DE8A; Wed, 17 Jan 2001 17:28:49 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 4D6CB5DE84; Wed, 17 Jan 2001 17:28:49 -0500 (EST)
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by segue.merit.edu (Postfix) with ESMTP id 3B8E05DE22
	for <aaa-wg@merit.edu>; Wed, 17 Jan 2001 17:28:48 -0500 (EST)
Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.ca.nortel.com;
          Wed, 17 Jan 2001 17:20:43 -0500
Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) 
          by zbl6c012.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id ZLK0B3FC; Wed, 17 Jan 2001 17:20:42 -0500
Received: from mitton.nortelnetworks.com (mitton.us.nortel.com [47.16.86.121]) 
          by zbl6c008.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id C22AA1CF; Wed, 17 Jan 2001 17:20:42 -0500
Message-Id: <4.3.2.7.2.20010117170939.00e016f0@ZBL6C008.corpeast.baynetworks.com>
X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 17 Jan 2001 17:21:37 -0500
To: aaa-wg@merit.edu, ietf-web@ietf.org
From: "David Mitton" <dmitton@nortelnetworks.com>
Subject: AAA-WG Archive access change
Cc: "David Mitton" <dmitton@nortelnetworks.com>,
        Bernard Aboba <aboba@internaut.com>, Randy Bush <randy@psg.com>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Orig: <dmitton@nortelnetworks.com>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


Our mailing list host has changed the way the list archiving is 
accessed.  Please discontinue using the archive URL mentioned on the AAA-WG 
web page.  And now use the following:

    http://www.merit.edu/mail.archives/aaa-wg/

Thanks.

The older URL works for now, but will be removed.

	Dave.
---------------------------------------------------------------
David Mitton                                  ESN: 248-4570
Advisor, Nortel Networks                      978-288-4570 Direct
ServiceWare, IP Mobility
Billerica, MA 01821                    dmitton@nortelnetworks.com




From owner-aaa-bof@merit.edu  Thu Jan 18 02:55:25 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20776
	for <aaa-archive@odin.ietf.org>; Thu, 18 Jan 2001 02:55:25 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 7879F5DE21; Thu, 18 Jan 2001 02:55:01 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id E22955DE59; Thu, 18 Jan 2001 02:55:00 -0500 (EST)
Received: from unipamplona.edu.co (r198h34.telecom.com.co [200.21.198.34])
	by segue.merit.edu (Postfix) with SMTP
	id C82405DD91; Thu, 18 Jan 2001 02:54:41 -0500 (EST)
Received: from libero.it by unipamplona.edu.co (SMI-8.6/SMI-SVR4)
	id DAA06879; Thu, 18 Jan 2001 03:14:26 -0500
From: <emed11@libero.it>
Subject: Obtain Biotech IPOs!    52
Date: Thu, 18 Jan 2001 02:51:12
Message-Id: <630.824581.405696@libero.it>
Reply-To: emed11@libero.it
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Apparently-To: <dunl@merit.edu>
Apparently-To: <aaa-wg@merit.edu>
Apparently-To: <ietf-udi@merit.edu>
Apparently-To: <ietf-ppp@merit.edu>
Apparently-To: <ipma@merit.edu>
Apparently-To: <thaler@merit.edu>
Apparently-To: <zeroconf@merit.edu>
Apparently-To: <akj@merit.edu>
Apparently-To: <netscarf-team@merit.edu>
Apparently-To: <nanog@merit.edu>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title></title>
</head>

<body bgcolor="#CCCCCC">

<div align="center">

<table border="2" width="550" cellpadding="14" cellspacing="5" bordercolor="#003366" bordercolorlight="#003366" bordercolordark="#003366">
<tr>
<td width="100%" bgcolor="#FFFFFF">

<p class="MsoBodyText" align="center"><b><font color="#003399" size="4" face="Verdana">Help Beta Test Our Site and Be Eligible to Purchase Shares of Future IPOs
In Which We Participate**</font></b></p>

<p class="MsoBodyText" align="left" style="text-align:left"><font size="2" face="Arial">eMedsecurities
has selected you as a possible participant to help test our online stock-trading
engine for knowledge-based investing in the life sciences. For your cooperation,
<b> you will be eligible to purchase shares of future IPOs</b> in which
we participate, for as long as
you maintain your account with us. This is limited to only <b>50 qualified
testers!&nbsp;</b>  <a href="mailto:emedsec@libero.it">Request More Information</a>.**</font></p>

<p class="MsoBodyText" align="center"><b><font size="3" face="Verdana" color="#003399">eMedsecurities… The Cure for the Common Portfolio!</font></b></p>

<p class="MsoBodyText" align="left" style="text-align:left"><font size="2" face="Arial">eMedsecurities provides you with a wealth of information, all compiled
in a single, easy-to-use resource.&nbsp; Learn about new research and upcoming treatments
for muscular dystrophy, multiple sclerosis, Parkinson's disease, Huntington's
chorea and much more.&nbsp; Obtain critical investment
information about the companies that are developing these treatments.&nbsp; eMedsecurities empowers you to make more informed investment decisions.
<a href="mailto:emedsec@libero.it">Request More Information</a>.**</font></p>

<p class="MsoNormal"><b><font size="2" face="Arial">Participation in eMedsecurities’ Beta Test allows you:</font></b></p>

<ul>
<li>

<p class="MsoNormal" style="mso-list: l1 level1 lfo2; tab-stops: list .5in"><b><font size="2" face="Arial" color="#003399">Eligibility to purchase shares
of IPOs in which eMedsecurities participates for as long as you maintain your account**</font></b></li>
<li>

<p class="MsoNormal" style="mso-list: l1 level1 lfo2; tab-stops: list .5in"><b><font size="2" face="Arial" color="#003399">Valuable research of the entire
product pipeline of companies, including stages of clinical development, by industry or specific disease</font></b></li>
<li>

<p class="MsoNormal" style="mso-list: l1 level1 lfo2; tab-stops: list .5in"><b><font size="2" face="Arial" color="#003399">Useful information about industry trends, recent developments and upcoming IPOs</font></b>
</li>
<li>

<p class="MsoNormal" style="mso-list: l1 level1 lfo2; tab-stops: list .5in"><b><font size="2" face="Arial" color="#003399">Commitment to customer service featuring our Live Customer Service Online</font></b></li>
<li>

<p class="MsoNormal" style="mso-list: l1 level1 lfo2; tab-stops: list .5in"><b><font size="2" face="Arial" color="#003399">Dedication to fast trade executions at the best possible
price.</font></b></li>
</ul>

<p align="left"><font size="2" face="Arial">The following guidelines will explain what we expect from an eMedsecurities Beta Tester:</font></p>

<ul>
<li>

<p align="left"><font size="2" face="Arial">Open a funded eMedsecurities account</font></li>
<li>

<p align="left"><font size="2" face="Arial">Visit our online trading site once a
week</font></li>
<li>

<p align="left"><font size="2" face="Arial">Execute trades through our web site in accordance with your normal
practice</font></li>
<li>

<p align="left"><font size="2" face="Arial">Submit feedback to eMedsecurities' development team through a
questionnaire sent via email</font></li>
<li>

<p align="left"><font size="2" face="Arial">Provide us with additional feedback regarding the site as needed.</font></li>
</ul>

<p align="left"><font size="2" face="Arial">The test is limited to only 50 Beta Testers so sign up now to be
considered!&nbsp; <a href="mailto:emedsec@libero.it">Request More Information</a>.**</font>

<p align="left"><b><font size="2" face="Arial">Please note:</font></b><font size="2" face="Arial">&nbsp;
All applications for the Beta Test must be
submitted by January 24, 2001 to be considered.</font>

<p align="left"><font face="Arial" size="2"><span style="mso-bidi-font-size: 12.0pt; mso-fareast-font-family: Times New Roman; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Please
be advised that your information will stay in our proprietary database and will
not be sold, traded, given or otherwise provided to outside vendors.&nbsp; We respect
your privacy.</span></font>

<p align="left">&nbsp;

<p align="left" style="line-height: 100%"><font face="Arial" size="1"><span style="mso-fareast-font-family: Times New Roman; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">By
submitting your information, you implicitly state that this is something that
interests you and that you<br>
agree to receive periodic emails from
eMedsecurities.</span></font>

<p class="MsoNormal"><font size="1" face="Arial">Research indicated that you might benefit from
our offer.&nbsp; To be removed instantly and permanently from our database, simply
<a href="mailto:emed11@libero.it">click here</a>.&nbsp;
We respect all removal requests.</font></p>

<font size="1" face="Arial">**<b> Restrictions Apply:</b>&nbsp; <span style="color:red"><b>Beta
test not open to residents of:&nbsp; HI, IL, MI, MN, MS, NE, NH, TN, TX.</b></span>&nbsp;&nbsp;
Initial Public Offerings are considered speculative investments and as such may not be appropriate for every
investor. If an investor chooses to participate in IPOs, there are certain restrictions that apply:&nbsp; <b><span style="color:red">Flipping</span>- </b>The first time an investor sells his/her shares within the first 30 days the issue is trading in the secondary market, that investor will not be allocated
shares for the next 90 days following the sale.&nbsp; The second time that investor “flips”, they will not be allocated IPO shares for 180 days.&nbsp; The third time that investor “flips”, they lose their IPO allocations permanently.&nbsp;<span style="color:red">
<b>Transferring shares</b></span><b>- </b>If
the investor transfers IPO shares out of their account within the first 30 days the issue is trading in the secondary market, they will permanently lose their IPO allocations.&nbsp;
<b>Beta investors will be chosen from all the applicants based on their income, net worth and investing experience.&nbsp;</b>
IPO shares will only be allocated from transactions in which eMedsecurities
participates in the underwriting.
A0008-1-A2</font>
</td>
</tr>
</table>

</div>

</body>

</html>



From owner-aaa-bof@merit.edu  Thu Jan 18 03:54:01 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21154
	for <aaa-archive@odin.ietf.org>; Thu, 18 Jan 2001 03:54:01 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id B64CA5DE43; Thu, 18 Jan 2001 03:53:36 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 93F975DE2D; Thu, 18 Jan 2001 03:53:36 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id EA6885DD8F
	for <aaa-wg@merit.edu>; Thu, 18 Jan 2001 03:53:34 -0500 (EST)
Received: from efra05-home.Germany.Sun.COM ([129.157.43.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA04239;
	Thu, 18 Jan 2001 00:53:32 -0800 (PST)
Received: from vayne (muc-isdn-7 [129.157.164.107])
	by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id JAA27341;
	Thu, 18 Jan 2001 09:53:30 +0100 (MET)
Date: Thu, 18 Jan 2001 10:03:57 +0100 (MET)
From: Erik Guttman <Erik.Guttman@germany.sun.com>
Reply-To: Erik Guttman <Erik.Guttman@germany.sun.com>
Subject: RE: Self Describing record formats for multiple (non-network-access)  usage types ...
To: Abhi Deshmukh <Abhi.Deshmukh@apogeenet.com>
Cc: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>, erik.guttman@germany.sun.com
In-Reply-To: "Your message with ID" <B11807D7A9C5D211876B0050040549E8B16841@POSTOFFICE>
Message-ID: <Roam.SIMC.2.0.6.979808637.12756.erikg@sun-ffm.germany>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Abhi,

You wrote:
> In particular the attributes of usage records in this case would be
> different than RADIUS, Mobile IP, etc. If the AAA transport can 
> accomodate different record formats, then the AAA framework will be 
> very attractive for *adoption* for billing systems for various services.

DIAMETER data, represented by AVPs, is grouped in commands.  Both
the commands and the AVPs are accompanied by centrally assigned
identifiers for all standardized extensions to the protocol.  Two
compliant implementations of the protocol will be able to recognize
known commands and data, as well as unknown, non-implemented
formats, as such.  Vendor extensions allow for non-standard messages
to be sent.  

In order to make progress with AAA standardization, the working
group narrowed its focus.  This does not mean that DIAMETER extensions 
couldn't be written for other purposes than network access.  

It is up to you to figure out what your requirements are and to assess 
whether DIAMETER, SNMP or whatever best fulfill them.

> One way to accomodate known and unknown record formats is to have the
> payload records describe themself. This way the transport can accomodate
> *any* usage record.

Self describing data records alone do not achieve much.  Labeling a 
record format as having fields with particular data types does not 
allow the record to be *interpreted.*  Correct interpretation requires 
common rules (a protocol) to be implemented by communicating parties
so they know *what to do* with the data when they get it.

Erik

._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
E r i k   G u t t m a n         SHORT msgs: 01728655497@d2-message.de
Sr Staff Engineer, Sun Microsystems       Email: erik.guttman@sun.com
Eichhoelzelstr. 7, 74915 Waibstadt Germany    Phone: +49 172 865 5497





From owner-aaa-bof@merit.edu  Thu Jan 18 05:04:30 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21560
	for <aaa-archive@odin.ietf.org>; Thu, 18 Jan 2001 05:04:29 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 620485DE8E; Thu, 18 Jan 2001 05:03:09 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 5084D5DE8C; Thu, 18 Jan 2001 05:03:09 -0500 (EST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by segue.merit.edu (Postfix) with ESMTP id 62CCE5DE8B
	for <aaa-wg@merit.edu>; Thu, 18 Jan 2001 05:03:03 -0500 (EST)
Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f0IA32d04932
	for <aaa-wg@merit.edu>; Thu, 18 Jan 2001 11:03:02 +0100 (MET)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jan 18 11:03:46 2001 +0100
Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58)
	id <Z2G9167Y>; Thu, 18 Jan 2001 11:03:01 +0100
Message-ID: <577066326047D41180AC00508B955DDA01D7FE56@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Pat.Calhoun@Eng.Sun.COM'" <Pat.Calhoun@Eng.Sun.COM>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: DIAMETER Base Protocol (Alpha 1) - Comments
Date: Thu, 18 Jan 2001 11:02:52 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Pat,

Here is a small contribution to your document, which I think is basically a great piece of work for DIAMETER. 


Section 1.0
-----------
In the second last paragraph, we have:
"Given that the server MAY send unsocilited messages to clients, it is possible for the server to also issue authentication requests."
Shouldn't it be AA-Challenge-Ind instead of authentication requests?

Should we make this document as independant as possible from the extension specifics, or do we want to keep this close relationship between the base and extension protocols? The thing is that we often read about authentication messages and so on in this document, which I don't think really belong here, right? Instead, this document should specify something as generic as a framework offering sessions in the implementing servers with certain APIs and caracteristics. What do you think? 

Section 2.0 - par.5
-------------------
"Session state (associated with a Session-Id) MUST be freed upon receipt of the Session-Termination-Request, Session-Termination-Answer, expiration of authorized service time in the Session-Timeout AVP, and according to rules established in a particular extension/application of DIAMETER."

I think this sentence is confusing me. Are you trying to show the real trigger for the session release, the STR (as in section 3.5.2), or the reasons why an STR could have been sent? It seems to me that the "Session-Termination-Answer, expiration of authorized service time in the Session-Timeout AVP, and according to rules established in a particular extension/application of DIAMETER." part is more related to original reasons why an STR has been sent. Also, it is confusing to read "authorized service time in the Session-Timeout AVP" when you can also refer to the reason that the "authorization-lifetime-AVP" might have time-out as well, which I assume would trigger an STR. I need more info from you if you want me to propose something else.

Section 2.1
-----------
While looking at the DIAMETER header format, it came to me that it might be cleaner to put the Vendor-ID before the Command-Code, since the Command-Code is worthless without the Vendor-ID and finding it first would make more sense. And then I thought, since we might remove the PCC and add more flags, shouldn't we add a flag indicating if a Vendor-ID is present at all in the message, just like in the AVP header? And since we are there, maybe we could put a 2 bit indicator (0: Base protocol, 1: Extension-ID, 2: Vendor-ID, 3: reserved) for the Extension-ID or Vendor-ID when present in the message (referring to ML on "Capabilities Negotiation and proxies"), which then would mean that the command-code is per Extension-ID and Vendor-ID base, completely independent of the Base protocol command-code. Maybe an AVP for the command-code field would be a better idea, because it could include the indicator bits and also could be used in a MRI in the Failed-AVP AVP, making obsolete the Un!
recognized-Command-Code AVP which lacks the information on the Vendor-ID AVP and Extension-ID. 

Section 2.2.3 - par.1
---------------------
"... seven data types" should be replaced with "the following data types", since we actually have 10 and it might keep changing.

Section 2.2.5
-------------
It would be more useful, at least for me, to have a list of attributes sorted by name, instead AVP codes, which are meaningless to human normal reading.

Section 2.5 - par.1
-------------------
"...the Device-Reboot-Ind message MUST contain one Host-IP-Address AVP for each potential IP address that MAY be locally used when transmitting DIAMETER messages."

Please, could you tell me briefly why we need to send all IP addresses of the device? I guess it is because the device is not registered into a DNS and we want to build an internal DNS inside the DIAMETER server along with the Host-Name AVP for message routing, right? Should we have a dynamic or static DNS in the server?

And referring to ML "Re: DIAMETER Base Protocol (Alpha 1)/2.5.1 Vendor-Name AVP", I also don´t quite see the purpose of the Vendor-Name AVP instead of the Vendor-ID AVP in the DRI. 

Section 5.0
-----------
The list of Error Types is a bit confusing with the one found in section 5.1 for MRI. I think it needs some rework. I can´t still figure out exactly how it should be, so maybe I'll come up with something later.

Section 5.1.2
-------------
I mentioned some ideas about this in the comments of section 2.1

Section 5.2.2
-------------
All other Result-Code starts a x001, so I thought it should also starts at 2001, instead of 2000.

Section 5.2.4
-------------
"...but MAY be able to satisfy the request in the future."
What does this mean exactly? Does it mean that a server should be able to resend the request in a few minutes without any specific changes to the message besides the timestamp for example? Should it be regarded as temporary congestion? If it is the case, then maybe we should think of moving the DIAMETER_AUTHENTICATION_REJECTED and DIAMETER_CONTRACTING_AVPS to the permanent failure section. I think that permanent result codes should be used in the rejected message even if the originating server can change AVPs in the message which has been rejected the first time for some reasons such as unsupported mandatory AVPs, because it is no longer the same message anyway, and the first message was really considered as a permanent failure in this particular period of time. 

Section 7.1.2
-------------
The 3rd paragraph should be removed.

Section 10.0
------------
About the shared secret, maybe we should also mention that it is used by the Encrypted-Payload AVP?

/Martin




From owner-aaa-bof@merit.edu  Thu Jan 18 05:19:14 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21710
	for <aaa-archive@odin.ietf.org>; Thu, 18 Jan 2001 05:19:14 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 1DD155DD8F; Thu, 18 Jan 2001 05:16:23 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 0D7C25DE59; Thu, 18 Jan 2001 05:16:23 -0500 (EST)
Received: from balinese.baltimore.ie (pc215-8.indigo.ie [194.125.215.8])
	by segue.merit.edu (Postfix) with ESMTP id 60FB05DD8F
	for <aaa-wg@merit.edu>; Thu, 18 Jan 2001 05:16:21 -0500 (EST)
Received: by balinese.baltimore.ie; id KAA04481; Thu, 18 Jan 2001 10:16:20 GMT
Received: from bobcat.ie.baltimore.com(10.153.25.10) by balinese.baltimore.ie via smap (V4.2)
	id xma004450; Thu, 18 Jan 01 10:16:16 GMT
Received: from baltimore.ie (ip187-24.ie.baltimore.com [10.153.24.187])
	by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id KAA30193;
	Thu, 18 Jan 2001 10:16:15 GMT
Message-ID: <3A66C275.449DF740@baltimore.ie>
Date: Thu, 18 Jan 2001 10:16:21 +0000
From: Stephen Farrell <stephen.farrell@baltimore.ie>
Reply-To: stephen.farrell@baltimore.ie
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Steven Glass - Solaris Software <Steven.Glass@east.sun.com>
Cc: Bernard Aboba <aboba@internaut.com>, Alain Zahm <Alain.Zahm@sema.fr>,
        aaa-wg@merit.edu
Subject: Re: Making the hard choices on AAA security
References: <Roam.SIMC.2.0.6.979769747.132.glass@purol.east>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit



Steven Glass - Solaris Software wrote:
> 
> >
> >
> > > Bernard Aboba wrote:
> > >
> > > A proxy can change an Access-Accept into an Access-Reject under the guise of "policy". However, an
> > > Access-Reject should never be changed to an Access-Accept. A good question is how this could be
> > > enforced, using any of the solutions that have been proposed.
> >
> > Not sure it could...
> 
>     Maybe not from the solutions proposed...

Just for clarity, CMS, Kerberos and any other self-respecting 
e2e security solution will offer e2e data integrity. The "not 
sure" etc. refers to allowing one type of change and 
preventing/detecting another, not to simple integrity.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com



From owner-aaa-bof@merit.edu  Thu Jan 18 05:26:14 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21736
	for <aaa-archive@odin.ietf.org>; Thu, 18 Jan 2001 05:26:13 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 21F015DE59; Thu, 18 Jan 2001 05:25:58 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 12DBB5DE58; Thu, 18 Jan 2001 05:25:58 -0500 (EST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by segue.merit.edu (Postfix) with ESMTP id AB1B85DE56
	for <aaa-wg@merit.edu>; Thu, 18 Jan 2001 05:25:56 -0500 (EST)
Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f0IAPtd23410
	for <aaa-wg@merit.edu>; Thu, 18 Jan 2001 11:25:55 +0100 (MET)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jan 18 11:26:39 2001 +0100
Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58)
	id <Z2G918X2>; Thu, 18 Jan 2001 11:25:54 +0100
Message-ID: <577066326047D41180AC00508B955DDA01D7FE57@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Pat.Calhoun@Eng.Sun.COM'" <Pat.Calhoun@Eng.Sun.COM>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0
Date: Thu, 18 Jan 2001 11:22:47 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Pat,

Comments making no sense to you are most probably related to my ignorance... However, I'd appreciate you help me out on this.


Section 3.0 - par.2
-------------------
It is weird to me that we refer to an Authorization-Lifetime AVP in the Base Protocol without having any authorization message in it. Now we have the Session-Timeout AVP and the Authorization-Lifetime AVP which are somehow competing together. Should the Authorization-Lifetime AVP be included in a specific extension, such as NASREQ, or is it because it might be used by several extensions without any specific meaning to the base protocol itself, which happens to be pretty much the same as the Session-Timeout AVP? My understanding is that there is not much to do with the Authorization-Lifetime AVP in the base protocol, since the action to take upon its expiration is defined in the NASREQ extension anyway, which is very specific. I guess that something more generic would be a Session-Timeout AVP which could trigger an STI when it expires that could lead to another re-authentication or something else in order to avoid the session to terminate right away. Then the NASREQ extension!
 could possibly override that meaning by defining its own Authorization-Lifetime AVP which would trigger a more efficient an AA-Challenge-Ind instead.

Section 3.2 and 3.3
-------------------
Can the server return a bigger value?
What the value 0 means? The same as if it was not there?
Which one has priority?

Section 3.5
-----------
"Since the Session-Id is typically tied to a particular service (i.e. Mobile IP, NASREQ, etc), the session termination messages are used to request that the service tied to the Session Id be terminated."

It seems to be against last paragraph of section 3.1, which is "Note that a Session-Id MAY be used by more than one extension (e.g. authentication for a specific service and accounting, both of which have separate extensions).

Section 3.5.2
-------------
What the Resource-Owner-NAI AVP used for in the STR? Is it for routing? I guess not, since the User-Name AVP is present. Can it be used in the server for any particular reason I don't see, since I think the active session should be aware of what's going on within itself, right?

Section 3.5.3
-------------
What is the purpose of the STA, since the session in the server and in the proxies should be released after the STR? What can the NAS or the server do if the STR is rejected and the resources are already released in the DIAMETER client and the proxies?

Section 3.5.4
-------------
AVP Code 293




From owner-aaa-bof@merit.edu  Thu Jan 18 06:39:47 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22075
	for <aaa-archive@odin.ietf.org>; Thu, 18 Jan 2001 06:39:46 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 6ED465DDA7; Thu, 18 Jan 2001 06:39:30 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 4E2875DE56; Thu, 18 Jan 2001 06:39:30 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by segue.merit.edu (Postfix) with ESMTP id 89AD55DDA7
	for <aaa-wg@merit.edu>; Thu, 18 Jan 2001 06:39:28 -0500 (EST)
Received: from esealnt462.al.sw.ericsson.se (esealnt462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f0IBdRC03122
	for <aaa-wg@merit.edu>; Thu, 18 Jan 2001 12:39:27 +0100 (MET)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Jan 18 12:39:27 2001 +0100
Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58)
	id <Z2G9FA8D>; Thu, 18 Jan 2001 12:39:26 +0100
Message-ID: <577066326047D41180AC00508B955DDA01D7FE58@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'stephen.farrell@baltimore.ie'" <stephen.farrell@baltimore.ie>,
        Steven Glass - Solaris Software <Steven.Glass@east.sun.com>
Cc: Bernard Aboba <aboba@internaut.com>, Alain Zahm <Alain.Zahm@sema.fr>,
        aaa-wg@merit.edu
Subject: RE: Making the hard choices on AAA security
Date: Thu, 18 Jan 2001 12:38:21 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Steven,

Could we possibly think of allowing the Result-Code AVP to be encrypted for e2e, using the Strong Security extension of course, which would prevent proxies to play around with its content when not allowed by the server?

Martin

-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
Sent: Thursday, January 18, 2001 11:16 AM
To: Steven Glass - Solaris Software
Cc: Bernard Aboba; Alain Zahm; aaa-wg@merit.edu
Subject: Re: Making the hard choices on AAA security




Steven Glass - Solaris Software wrote:
> 
> >
> >
> > > Bernard Aboba wrote:
> > >
> > > A proxy can change an Access-Accept into an Access-Reject under the guise of "policy". However, an
> > > Access-Reject should never be changed to an Access-Accept. A good question is how this could be
> > > enforced, using any of the solutions that have been proposed.
> >
> > Not sure it could...
> 
>     Maybe not from the solutions proposed...

Just for clarity, CMS, Kerberos and any other self-respecting 
e2e security solution will offer e2e data integrity. The "not 
sure" etc. refers to allowing one type of change and 
preventing/detecting another, not to simple integrity.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com



From owner-aaa-bof@merit.edu  Thu Jan 18 07:52:47 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22635
	for <aaa-archive@odin.ietf.org>; Thu, 18 Jan 2001 07:52:46 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 58E8D5DE0C; Thu, 18 Jan 2001 07:49:50 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 3A47F5DE6A; Thu, 18 Jan 2001 07:49:50 -0500 (EST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by segue.merit.edu (Postfix) with ESMTP id 1B9D85DE0C
	for <aaa-wg@merit.edu>; Thu, 18 Jan 2001 07:49:44 -0500 (EST)
Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f0ICnhd02434
	for <aaa-wg@merit.edu>; Thu, 18 Jan 2001 13:49:43 +0100 (MET)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jan 18 13:50:27 2001 +0100
Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58)
	id <Z2G9F1GS>; Thu, 18 Jan 2001 13:49:41 +0100
Message-ID: <577066326047D41180AC00508B955DDA01D7FE59@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Erik Guttman'" <Erik.Guttman@germany.sun.com>,
        Abhi Deshmukh <Abhi.Deshmukh@apogeenet.com>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: RE: Self Describing record formats for multiple (non-network-acce
	ss) usage types ...
Date: Thu, 18 Jan 2001 13:49:44 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Abhi,

Maybe the discussion on this ML "Choice of Data Model SMI vs XML vs. UML)" could give you a better idea of what is being discussed about an AAA dictionnary at the moment. I am not sure exactly where that discussion is going (SMIng???), but I'd like to see it going towards what you want as well, which I think is defining new attributes (AVPs) in a flexible way at run-time and being able to output them for accounting purposes, for example, as is to an accounting server. Since the logging format and the accounting format is no longer ADIF, I'm not sure what to expect besides the dumping of AVPs at the moment. Refer to ML "DISCUSSION REQUESTED: ADIF, Batching, M bit" for the following comment:

> However, I think that specifying a recommended XML or SMI format for the
> accounting file that is written on the server MAY be a desirable goal.

Hope it helps,
Martin


-----Original Message-----
From: Erik Guttman [mailto:Erik.Guttman@germany.sun.com]
Sent: Thursday, January 18, 2001 10:04 AM
To: Abhi Deshmukh
Cc: 'aaa-wg@merit.edu'; erik.guttman@germany.sun.com
Subject: RE: Self Describing record formats for multiple
(non-network-access) usage types ...


Abhi,

You wrote:
> In particular the attributes of usage records in this case would be
> different than RADIUS, Mobile IP, etc. If the AAA transport can 
> accomodate different record formats, then the AAA framework will be 
> very attractive for *adoption* for billing systems for various services.

DIAMETER data, represented by AVPs, is grouped in commands.  Both
the commands and the AVPs are accompanied by centrally assigned
identifiers for all standardized extensions to the protocol.  Two
compliant implementations of the protocol will be able to recognize
known commands and data, as well as unknown, non-implemented
formats, as such.  Vendor extensions allow for non-standard messages
to be sent.  

In order to make progress with AAA standardization, the working
group narrowed its focus.  This does not mean that DIAMETER extensions 
couldn't be written for other purposes than network access.  

It is up to you to figure out what your requirements are and to assess 
whether DIAMETER, SNMP or whatever best fulfill them.

> One way to accomodate known and unknown record formats is to have the
> payload records describe themself. This way the transport can accomodate
> *any* usage record.

Self describing data records alone do not achieve much.  Labeling a 
record format as having fields with particular data types does not 
allow the record to be *interpreted.*  Correct interpretation requires 
common rules (a protocol) to be implemented by communicating parties
so they know *what to do* with the data when they get it.

Erik

._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
E r i k   G u t t m a n         SHORT msgs: 01728655497@d2-message.de
Sr Staff Engineer, Sun Microsystems       Email: erik.guttman@sun.com
Eichhoelzelstr. 7, 74915 Waibstadt Germany    Phone: +49 172 865 5497





From owner-aaa-bof@merit.edu  Thu Jan 18 10:26:47 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26443
	for <aaa-archive@odin.ietf.org>; Thu, 18 Jan 2001 10:26:47 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 00A305DE82; Thu, 18 Jan 2001 10:25:55 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id DAD935DE81; Thu, 18 Jan 2001 10:25:54 -0500 (EST)
Received: from localhost.ipunplugged.com (unknown [195.42.212.161])
	by segue.merit.edu (Postfix) with ESMTP id C72B75DE7D
	for <aaa-wg@merit.edu>; Thu, 18 Jan 2001 10:25:52 -0500 (EST)
Received: from fredrikj (c8.local.ipunplugged.com [192.168.4.207])
	by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id QAA12397
	for <aaa-wg@merit.edu>; Thu, 18 Jan 2001 16:26:45 +0100
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "AAA Listan" <aaa-wg@merit.edu>
Subject: Comments on draft-calhoun-diameter-18.txt
Date: Thu, 18 Jan 2001 16:28:23 +0100
Message-ID: <MJEMJBGGCLLDLFFAHLJKAEDJCFAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000C_01C0816B.AD7CB990"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_000C_01C0816B.AD7CB990
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

The <Grouped-AVP> is missing in the table in section 2.2.5

/Fredrik


----------------------------------------------------------------------------
-------
Fredrik Johansson                    W: +46 (0)8 725 5916
Interactive People Unplugged     M: +46 (0)70 786 5035
mailto:fredrik.johansson@ipunplugged.com
http://www.ipunplugged.com



------=_NextPart_000_000C_01C0816B.AD7CB990
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D790025314-18012001>The=20
&lt;Grouped-AVP&gt; is missing in the table in section =
2.2.5</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D790025314-18012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D790025314-18012001>/Fredrik</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D790025314-18012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D790025314-18012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#008000 face=3DArial=20
size=3D2>----------------------------------------------------------------=
-------------------</FONT></DIV>
<DIV><FONT color=3D#008000 face=3DArial size=3D2>Fredrik=20
Johansson&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;W:=20
+46 (0)8 725 5916</FONT></DIV>
<DIV><FONT color=3D#008000 face=3DArial size=3D2>Interactive People=20
Unplugged&nbsp;&nbsp;&nbsp;&nbsp; M: +46 (0)70 786 5035</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"mailto:fredrik.johansson@ipunplugged.com">mailto:fredrik.johansso=
n@ipunplugged.com</A></FONT></DIV>
<DIV><FONT color=3D#008000 face=3DArial size=3D2><A=20
href=3D"http://www.ipunplugged.com/">http://www.ipunplugged.com</A></FONT=
></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_000C_01C0816B.AD7CB990--




From owner-aaa-bof@merit.edu  Thu Jan 18 15:52:40 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05169
	for <aaa-archive@odin.ietf.org>; Thu, 18 Jan 2001 15:52:39 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 9D20F5E151; Thu, 18 Jan 2001 15:29:55 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id DBBD75E4FE; Thu, 18 Jan 2001 15:25:50 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 9FEDA5DF39
	for <aaa-wg@merit.edu>; Thu, 18 Jan 2001 15:12:45 -0500 (EST)
Received: from purol.East.Sun.COM ([129.148.9.11])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA20230;
	Thu, 18 Jan 2001 12:12:39 -0800 (PST)
Received: from onion.east.sun.com (onion [129.148.174.110])
	by purol.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id PAA04884;
	Thu, 18 Jan 2001 15:12:38 -0500 (EST)
Date: Thu, 18 Jan 2001 15:12:33 -0500 (EST)
From: Steven Glass - Solaris Software <Steven.Glass@east.sun.com>
Reply-To: Steven Glass - Solaris Software <Steven.Glass@east.sun.com>
Subject: RE: Making the hard choices on AAA security
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Cc: "'stephen.farrell@baltimore.ie'" <stephen.farrell@baltimore.ie>,
        Steven Glass - Solaris Software <Steven.Glass@east.sun.com>,
        Bernard Aboba <aboba@internaut.com>, Alain Zahm <Alain.Zahm@sema.fr>,
        aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FE58@eestqnt104.es.eu.ericsson.se>
Message-ID: <Roam.SIMC.2.0.6.979848753.15039.glass@purol.east>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Steven,
> 
> Could we possibly think of allowing the Result-Code AVP to be encrypted for
> e2e, using the Strong Security extension of course, which would prevent
> proxies to play around with its content when not allowed by the server?
> 
> Martin

    Sure, why not?  (If you're asking for a mobileip-centric viewpoint, I
don't see why this would generate any issues).  In this case, if a proxy
decided it wanted to deny (even if only based on the _unencrypted_ portion of
the answer it got back from the AAA server), it could always throw away
[x-bits of] the packet, and generate it's own reply - e.g. "error 666: I
didn't like the AAA server's tone".  This means some wasted cycles on securing
the e2e piece at the AAA server, but that possibility will never go away. 
Whenever there's a proxy involved, there's always going to have to be non-e2e
encrypted bits in the AAA server's response (if only based on likely policies
at the proxy), and Proxy decisions can always be made based on that info.

                              Cheers,
                                  Steve

> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
> Sent: Thursday, January 18, 2001 11:16 AM
> To: Steven Glass - Solaris Software
> Cc: Bernard Aboba; Alain Zahm; aaa-wg@merit.edu
> Subject: Re: Making the hard choices on AAA security
> 
> 
> 
> 
> Steven Glass - Solaris Software wrote:
> > 
> > >
> > >
> > > > Bernard Aboba wrote:
> > > >
> > > > A proxy can change an Access-Accept into an Access-Reject under the guise of "policy". However, an
> > > > Access-Reject should never be changed to an Access-Accept. A good question is how this could be
> > > > enforced, using any of the solutions that have been proposed.
> > >
> > > Not sure it could...
> > 
> >     Maybe not from the solutions proposed...
> 
> Just for clarity, CMS, Kerberos and any other self-respecting 
> e2e security solution will offer e2e data integrity. The "not 
> sure" etc. refers to allowing one type of change and 
> preventing/detecting another, not to simple integrity.
> 
> Stephen.
> 
> -- 
> ____________________________________________________________
> Stephen Farrell         				   
> Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> 39 Parkgate Street,                     fax: +353 1 881 7000
> Dublin 8.                mailto:stephen.farrell@baltimore.ie
> Ireland                             http://www.baltimore.com





From owner-aaa-bof@merit.edu  Thu Jan 18 16:44:42 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05881
	for <aaa-archive@odin.ietf.org>; Thu, 18 Jan 2001 16:44:42 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id A1DC25DE93; Thu, 18 Jan 2001 16:29:25 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 01C435DF21; Thu, 18 Jan 2001 16:13:36 -0500 (EST)
Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110])
	by segue.merit.edu (Postfix) with ESMTP id 101B75DF24
	for <aaa-wg@merit.edu>; Thu, 18 Jan 2001 15:45:46 -0500 (EST)
Received: from phoenix (unknown [198.108.5.3])
	by aaa.interlinknetworks.com (Postfix) with SMTP
	id 450A272; Thu, 18 Jan 2001 15:45:54 -0500 (EST)
From: "Bob Kopacz" <BKopacz@InterlinkNetworks.com>
To: "Pat Calhoun" <Pat.Calhoun@Eng.Sun.COM>
Cc: "Aaa-Wg" <aaa-wg@merit.edu>
Subject: DIAMETER Base Protocol (18-Alpha 1) draft / MRI 
Date: Thu, 18 Jan 2001 15:45:10 -0500
Message-ID: <NEBBKEONLKEDJCMHGHPIIEHLCAAA.BKopacz@InterlinkNetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pat,

Here are some questions on the DIAMETER Base Protocol (18-Alpha 1)
draft.  The gist of what follows is:

(a) the draft's phrase "Extension Response + Result-Code" is ambiguous, and

(b) There may be error conditions where an MRI can't be sent, yet no
appropriate extension response is available.



5.0  Error Reporting
--------------------

The draft says:

   "Extension Response + Result-Code" indicates that the appropriate
   Response to the message MUST be sent with the Result-Code AVP set to
   a value that enables the peer to understand the nature of the
   problem.

Problem 1: The phrase "Extension Response + Result-Code" is
ambiguous.  Does "Extension Response + Result-Code" mean "a response
with an extension-specific command code", or "a response specified
by the extension, but which may be an MRI"?  If the first meaning,
perhaps the draft-18's text could be clarified by adding the
following sentence to the paragraph:

   The Response has an extension-specific command code.

- - -

Draft-18 specifies a more limited role for the MRI message.  That
is, between draft-17 and draft-18, some of the 'X's in the following
table from section 5.0 have shifted from the "Send
Message-Reject-Ind" column into the "Extension Response +
Result-Code" column.

Draft-17 said:

>    Error Type        Ignore Message          Send         Extension
>                                       Message-Reject-Ind  Response +
>                                                           Result-Code
>    Bad Message              X
>    Unknown Command                            X
>    Unknown AVP                                X
>    Bad Value                                  X
>    Extension Error                                            X

Draft-18-Alpha 1 says:

>    Error Type        Ignore Message          Send         Extension
>                                       Message-Reject-Ind  Response +
>                                                           Result-Code
>    Bad Message              X
>    Unknown Command                            X
>    Unknown AVP                                                X
>    Bad AVP Value                                              X
>    Extension Error                                            X

This shift to an extension-specific response is probably because a
proxy which routes on Diameter extension wouldn't know how to route
an MRI.

Problem 2: Assuming that "Extension Response + Result-Code" means "a
response with an extension-specific command code", it seems like the
MRI is limited to dealing with (a) DRI errors and (b) Unknown
Command errors.  But some recent mailing list questions suggest that
there may be error conditions other than (a) or (b), where no
appropriate extension response is available.  

[One of the emails I am referring to is the "DIAMETER Base Protocol
(18-Alpha 1)" draft / 5.0 Error Reporting" email of 16-Jan-2001,
suggesting that a receiver of a reply packet which contains a bad
AVP may want to send an MRI.  Another is the "Re: Comments on
draft-calhoun-diameter-18.txt" email of 17-Jan-2001, suggesting that
an MRI is a candidate to recover from a looped proxy chain.]


--------------------------------------------------------------
Bob Kopacz                mailto:bkopacz@interlinknetworks.com
Interlink Networks, Inc.  http://www.interlinknetworks.com
[Tel] 734-821-1230        




From owner-aaa-bof@merit.edu  Thu Jan 18 17:29:16 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06400
	for <aaa-archive@odin.ietf.org>; Thu, 18 Jan 2001 17:29:16 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 6EEEC5DDE0; Thu, 18 Jan 2001 17:12:50 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 022035E042; Thu, 18 Jan 2001 16:57:14 -0500 (EST)
Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110])
	by segue.merit.edu (Postfix) with ESMTP id B76455E474
	for <aaa-wg@merit.edu>; Thu, 18 Jan 2001 16:49:36 -0500 (EST)
Received: from phoenix (unknown [198.108.5.3])
	by aaa.interlinknetworks.com (Postfix) with SMTP
	id E446772; Thu, 18 Jan 2001 16:49:44 -0500 (EST)
From: "Bob Kopacz" <BKopacz@InterlinkNetworks.com>
To: "Pat Calhoun" <Pat.Calhoun@Eng.Sun.COM>
Cc: "Aaa-Wg" <aaa-wg@merit.edu>
Subject: Comment on DIAMETER Base Protocol / Port 1812
Date: Thu, 18 Jan 2001 16:48:59 -0500
Message-ID: <NEBBKEONLKEDJCMHGHPIMEHLCAAA.BKopacz@InterlinkNetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pat,

The Diameter base drafts say: 

   "The base DIAMETER protocol is run over SCTP [26] port 1812."

I'm not sure 1812 is a given; the draft might better say 

   "The base DIAMETER protocol is run over SCTP [26] port [TBD]."


Discussion:
-----------
IANA's "well known port numbers" currently assign port 1812 
to RADIUS/UDP and RADIUS/TCP.  Specifically, IANA's entry
for port 1812 is:

> Port Assignments:
>
> Keyword         Decimal    Description    Refrences
> -------         -------    -----------    ---------                  
> [...]
> radius          1812/tcp    RADIUS        Carl Rigney <cdr@...>
> radius          1812/udp    RADIUS        Carl Rigney <cdr@...>


When I look over IANA's other assigned ports, it seems their 
consistent notion is that the port is associated with exactly 
one application.  So assigning 1812 to both Radius and Diameter 
would result in the unusual:

> Port Assignments:
>
> Keyword         Decimal    Description    Refrences
> -------         -------    -----------    ---------                  
> [...]
> radius          1812/tcp    RADIUS        Carl Rigney <cdr@...>
> radius          1812/udp    RADIUS        Carl Rigney <cdr@...>
> diameter        1812/tcp    DIAMETER      Pat Calhoun <...>
> diameter        1812/sctp   DIAMETER      Pat Calhoun <...>
> #                           

So I'm guessing that Diameter would end up with a brand new port
number (and that PCC will be eliminated).



--------------------------------------------------------------
Bob Kopacz                mailto:bkopacz@interlinknetworks.com
Interlink Networks, Inc.  http://www.interlinknetworks.com
[Tel] 734-821-1230        




From owner-aaa-bof@merit.edu  Thu Jan 18 17:47:24 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06520
	for <aaa-archive@odin.ietf.org>; Thu, 18 Jan 2001 17:47:23 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 17A185E2B9; Thu, 18 Jan 2001 17:40:51 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 749895DF40; Thu, 18 Jan 2001 17:30:18 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 1ABF95E08B
	for <aaa-wg@merit.edu>; Thu, 18 Jan 2001 17:17:19 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09340;
	Thu, 18 Jan 2001 14:17:13 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA28734;
	Thu, 18 Jan 2001 14:17:11 -0800 (PST)
Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id KAA20317;
	Thu, 18 Jan 2001 10:01:52 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Message-Id: <200101181801.KAA20317@nasnfs.eng.sun.com>
Date: Thu, 18 Jan 2001 10:00:21 -0800
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "Steven Glass - Solaris Software" <Steven.Glass@east.sun.com>,
        "'stephen.farrell@baltimore.ie'" <stephen.farrell@baltimore.ie>
Cc: <aaa-wg@merit.edu>, "Alain Zahm" <Alain.Zahm@sema.fr>,
        "Bernard Aboba" <aboba@internaut.com>
Reply-To: <Pat.Calhoun@Eng.Sun.COM>
Subject: RE: Making the hard choices on AAA security
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

For proxies that wish to maintain state information, not having access
to the result code would be a problem.

Perhaps e2e authenticated, but not encrypted.

PatC
>Steven,
>
>Could we possibly think of allowing the Result-Code AVP to be encrypted for e2e,
>using the Strong Security extension of course, which would prevent proxies to
>play around with its content when not allowed by the server?
>
>Martin
>
>-----Original Message-----
>From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
>Sent: Thursday, January 18, 2001 11:16 AM
>To: Steven Glass - Solaris Software
>Cc: Bernard Aboba; Alain Zahm; aaa-wg@merit.edu
>Subject: Re: Making the hard choices on AAA security
>
>
>
>
>Steven Glass - Solaris Software wrote:
>> 
>> >
>> >
>> > > Bernard Aboba wrote:
>> > >
>> > > A proxy can change an Access-Accept into an Access-Reject under the guise
>of "policy". However, an
>> > > Access-Reject should never be changed to an Access-Accept. A good question
>is how this could be
>> > > enforced, using any of the solutions that have been proposed.
>> >
>> > Not sure it could...
>> 
>>     Maybe not from the solutions proposed...
>
>Just for clarity, CMS, Kerberos and any other self-respecting 
>e2e security solution will offer e2e data integrity. The "not 
>sure" etc. refers to allowing one type of change and 
>preventing/detecting another, not to simple integrity.
>
>Stephen.
>
>-- 
>____________________________________________________________
>Stephen Farrell         				   
>Baltimore Technologies,   tel: (direct line) +353 1 881 6716
>39 Parkgate Street,                     fax: +353 1 881 7000
>Dublin 8.                mailto:stephen.farrell@baltimore.ie
>Ireland                             http://www.baltimore.com
>





From owner-aaa-bof@merit.edu  Thu Jan 18 17:59:44 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06664
	for <aaa-archive@odin.ietf.org>; Thu, 18 Jan 2001 17:59:43 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 6CB355DFF4; Thu, 18 Jan 2001 17:31:52 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 3FA6B5DDD8; Thu, 18 Jan 2001 17:22:44 -0500 (EST)
Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110])
	by segue.merit.edu (Postfix) with ESMTP id 9F7A95E296
	for <aaa-wg@merit.edu>; Thu, 18 Jan 2001 17:05:58 -0500 (EST)
Received: from phoenix (unknown [198.108.5.3])
	by aaa.interlinknetworks.com (Postfix) with SMTP id E42F772
	for <aaa-wg@merit.edu>; Thu, 18 Jan 2001 17:06:06 -0500 (EST)
From: "Bob Kopacz" <BKopacz@InterlinkNetworks.com>
To: "Aaa-Wg" <aaa-wg@merit.edu>
Subject: Diameter SCTP-vs-TCP Transport Issues 
Date: Thu, 18 Jan 2001 17:05:21 -0500
Message-ID: <NEBBKEONLKEDJCMHGHPIEEHMCAAA.BKopacz@InterlinkNetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Here are some Diameter transport issues.  I'm not sure if this is
better targeted as comments on the "AAA Problem Statements" or the
"DIAMETER Base Protocol (18-Alpha 1)" draft.


It's been stated that the AAA Solutions paper and the Diameter base
document need to address and specify the transport mappings, e.g.
which end initiates a connection, re-establishing dropped
connections, whether long idle connections may be dropped.


Here are some issues to include on this list, if not already there:


It looks like Diameter may be transported over TCP rather than SCTP.
If so:

1. Because of the firewall problem (firewalls on the path between
two Diameter peers may not recognize the new SCTP protocol type in
the IP header, and may discard the SCTP packets), is it a valid
notion for a NAS or AAA Server to attempt an SCTP connection to a
Diameter peer, and to fall back to TCP upon failure; the thought
being that the firewall is hosing SCTP packets or that the peer's
SCTP service is not running?

2. Where the Diameter specification relies on the more robust SCTP
transport layer, compensations need to be made for features that
SCTP provides that TCP does not provide.  As one tiny example, SCTP
provides a heartbeat; so the Diameter ULP might try to set up TCP to
run its keepalive timer.  The Diameter specification needs to
indicate the places where it needs to drive certain transports
in a specific manner.

3. The DRI carries multiple IP addresses associated with the sender,
I assume for SCTP's multi-homed host support.  Since Diameter/TCP
peers will communicate using a single IP address at each end, would
a DRI for a TCP peer eliminate these unusable alternate addresses?
Or is there some unstated notion that these alternate peer IP
addresses would somehow be used over TCP transports?

 




From owner-aaa-bof@merit.edu  Thu Jan 18 18:56:57 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07341
	for <aaa-archive@odin.ietf.org>; Thu, 18 Jan 2001 18:56:57 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 51A935E0BB; Thu, 18 Jan 2001 18:33:30 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 32D365E034; Thu, 18 Jan 2001 17:58:11 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id C8F175E0B5
	for <aaa-wg@merit.edu>; Thu, 18 Jan 2001 17:34:25 -0500 (EST)
Received: from purol.East.Sun.COM ([129.148.9.11])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19226;
	Thu, 18 Jan 2001 14:33:41 -0800 (PST)
Received: from onion.east.sun.com (onion [129.148.174.110])
	by purol.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with SMTP id RAA16848;
	Thu, 18 Jan 2001 17:33:40 -0500 (EST)
Date: Thu, 18 Jan 2001 17:33:36 -0500 (EST)
From: Steven Glass - Solaris Software <Steven.Glass@east.sun.com>
Reply-To: Steven Glass - Solaris Software <Steven.Glass@east.sun.com>
Subject: RE: Making the hard choices on AAA security
To: Pat.Calhoun@eng.sun.com
Cc: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        Steven Glass - Solaris Software <Steven.Glass@east.sun.com>,
        "'stephen.farrell@baltimore.ie'" <stephen.farrell@baltimore.ie>,
        aaa-wg@merit.edu, Alain Zahm <Alain.Zahm@sema.fr>,
        Bernard Aboba <aboba@internaut.com>
In-Reply-To: "Your message with ID" <200101181801.KAA20317@nasnfs.eng.sun.com>
Message-ID: <Roam.SIMC.2.0.6.979857216.8155.glass@purol.east>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> For proxies that wish to maintain state information, not having access
> to the result code would be a problem.
> 
> Perhaps e2e authenticated, but not encrypted.

    This is the foundation of my point, and of course Pat said it better than
I.  I took it as a given that if the AAA response is e2e encrypted, the
approval info has to be some place else for the proxy to see!

                              Cheers,
                                  Steve




From owner-aaa-bof@merit.edu  Thu Jan 18 19:20:30 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07552
	for <aaa-archive@odin.ietf.org>; Thu, 18 Jan 2001 19:20:30 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 268A15DF87; Thu, 18 Jan 2001 19:06:01 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 2DF695DEF2; Thu, 18 Jan 2001 18:39:55 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id CB51E5E01C
	for <aaa-wg@merit.edu>; Thu, 18 Jan 2001 18:16:21 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15995;
	Thu, 18 Jan 2001 15:16:20 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA13607;
	Thu, 18 Jan 2001 15:16:18 -0800 (PST)
Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id PAA08118;
	Thu, 18 Jan 2001 15:15:48 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Message-Id: <200101182315.PAA08118@nasnfs.eng.sun.com>
Date: Thu, 18 Jan 2001 15:13:57 -0800
To: "Bob Kopacz" <BKopacz@InterlinkNetworks.com>,
        "Pat Calhoun" <Pat.Calhoun@eng.sun.com>
Cc: "Aaa-Wg" <aaa-wg@merit.edu>
Reply-To: <Pat.Calhoun@eng.sun.com>
Subject: Re: Comment on DIAMETER Base Protocol / Port 1812
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


>Hi Pat,
>
>The Diameter base drafts say: 
>
>   "The base DIAMETER protocol is run over SCTP [26] port 1812."
>
>I'm not sure 1812 is a given; the draft might better say 
>
>   "The base DIAMETER protocol is run over SCTP [26] port [TBD]."

Until I do get a port number, you are correct. However, a port number needs
to be specified at the moment for interoperability.

>
>
>Discussion:
>-----------
>IANA's "well known port numbers" currently assign port 1812 
>to RADIUS/UDP and RADIUS/TCP.  Specifically, IANA's entry
>for port 1812 is:
>
>> Port Assignments:
>>
>> Keyword         Decimal    Description    Refrences
>> -------         -------    -----------    ---------                  
>> [...]
>> radius          1812/tcp    RADIUS        Carl Rigney <cdr@...>
>> radius          1812/udp    RADIUS        Carl Rigney <cdr@...>
>
>
>When I look over IANA's other assigned ports, it seems their 
>consistent notion is that the port is associated with exactly 
>one application.  So assigning 1812 to both Radius and Diameter 
>would result in the unusual:

I am not sure this is correct, but I must admit that having port 1812 for
TCP reserved for RADIUS is very odd. I seriously doubt that IANA would
allow such waste to occur. Perhaps this is an error, and I will look into
this.


>
>> Port Assignments:
>>
>> Keyword         Decimal    Description    Refrences
>> -------         -------    -----------    ---------                  
>> [...]
>> radius          1812/tcp    RADIUS        Carl Rigney <cdr@...>
>> radius          1812/udp    RADIUS        Carl Rigney <cdr@...>
>> diameter        1812/tcp    DIAMETER      Pat Calhoun <...>
>> diameter        1812/sctp   DIAMETER      Pat Calhoun <...>
>> #                           
>
>So I'm guessing that Diameter would end up with a brand new port
>number (and that PCC will be eliminated).

Yes, the PCC will be eliminated (in fact, I thought I had in -18).

PatC




From owner-aaa-bof@merit.edu  Thu Jan 18 19:21:19 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07568
	for <aaa-archive@odin.ietf.org>; Thu, 18 Jan 2001 19:21:19 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 7C1DA5DE8D; Thu, 18 Jan 2001 19:06:08 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 4671A5E01C; Thu, 18 Jan 2001 18:40:01 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id E559A5DF85
	for <aaa-wg@merit.edu>; Thu, 18 Jan 2001 18:18:09 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA08008;
	Thu, 18 Jan 2001 15:18:07 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA13979;
	Thu, 18 Jan 2001 15:18:05 -0800 (PST)
Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id PAA08137;
	Thu, 18 Jan 2001 15:17:33 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Message-Id: <200101182317.PAA08137@nasnfs.eng.sun.com>
Date: Thu, 18 Jan 2001 15:15:45 -0800
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>,
        "'Pat.Calhoun@Eng.Sun.COM'" <Pat.Calhoun@eng.sun.com>
Reply-To: <Pat.Calhoun@eng.sun.com>
Subject: Re: DIAMETER Base Protocol (Alpha 1) - Comments
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

Martin,

Thanks for the great comments. I am travelling at the moment, and will address
these tomorrow (just want to make sure that you don't think I am ignoring 
this e-mail).

PatC

>Pat,
>
>Here is a small contribution to your document, which I think is basically a
>great piece of work for DIAMETER. 
>
>
>Section 1.0
>-----------
>In the second last paragraph, we have:
>"Given that the server MAY send unsocilited messages to clients, it is possible
>for the server to also issue authentication requests."
>Shouldn't it be AA-Challenge-Ind instead of authentication requests?
>
>Should we make this document as independant as possible from the extension
>specifics, or do we want to keep this close relationship between the base and
>extension protocols? The thing is that we often read about authentication
>messages and so on in this document, which I don't think really belong here,
>right? Instead, this document should specify something as generic as a framework
>offering sessions in the implementing servers with certain APIs and
>caracteristics. What do you think? 
>
>Section 2.0 - par.5
>-------------------
>"Session state (associated with a Session-Id) MUST be freed upon receipt of the
>Session-Termination-Request, Session-Termination-Answer, expiration of
>authorized service time in the Session-Timeout AVP, and according to rules
>established in a particular extension/application of DIAMETER."
>
>I think this sentence is confusing me. Are you trying to show the real trigger
>for the session release, the STR (as in section 3.5.2), or the reasons why an
>STR could have been sent? It seems to me that the "Session-Termination-Answer,
>expiration of authorized service time in the Session-Timeout AVP, and according
>to rules established in a particular extension/application of DIAMETER." part is
>more related to original reasons why an STR has been sent. Also, it is confusing
>to read "authorized service time in the Session-Timeout AVP" when you can also
>refer to the reason that the "authorization-lifetime-AVP" might have time-out as
>well, which I assume would trigger an STR. I need more info from you if you want
>me to propose something else.
>
>Section 2.1
>-----------
>While looking at the DIAMETER header format, it came to me that it might be
>cleaner to put the Vendor-ID before the Command-Code, since the Command-Code is
>worthless without the Vendor-ID and finding it first would make more sense. And
>then I thought, since we might remove the PCC and add more flags, shouldn't we
>add a flag indicating if a Vendor-ID is present at all in the message, just like
>in the AVP header? And since we are there, maybe we could put a 2 bit indicator
>(0: Base protocol, 1: Extension-ID, 2: Vendor-ID, 3: reserved) for the
>Extension-ID or Vendor-ID when present in the message (referring to ML on
>"Capabilities Negotiation and proxies"), which then would mean that the
>command-code is per Extension-ID and Vendor-ID base, completely independent of
>the Base protocol command-code. Maybe an AVP for the command-code field would be
>a better idea, because it could include the indicator bits and also could be
>used in a MRI in the Failed-AVP AVP, making obsolete the Un!
>recognized-Command-Code AVP which lacks the information on the Vendor-ID AVP and
>Extension-ID. 
>
>Section 2.2.3 - par.1
>---------------------
>"... seven data types" should be replaced with "the following data types", since
>we actually have 10 and it might keep changing.
>
>Section 2.2.5
>-------------
>It would be more useful, at least for me, to have a list of attributes sorted by
>name, instead AVP codes, which are meaningless to human normal reading.
>
>Section 2.5 - par.1
>-------------------
>"...the Device-Reboot-Ind message MUST contain one Host-IP-Address AVP for each
>potential IP address that MAY be locally used when transmitting DIAMETER
>messages."
>
>Please, could you tell me briefly why we need to send all IP addresses of the
>device? I guess it is because the device is not registered into a DNS and we
>want to build an internal DNS inside the DIAMETER server along with the
>Host-Name AVP for message routing, right? Should we have a dynamic or static DNS
>in the server?
>
>And referring to ML "Re: DIAMETER Base Protocol (Alpha 1)/2.5.1 Vendor-Name
>AVP", I also don´t quite see the purpose of the Vendor-Name AVP instead of the
>Vendor-ID AVP in the DRI. 
>
>Section 5.0
>-----------
>The list of Error Types is a bit confusing with the one found in section 5.1 for
>MRI. I think it needs some rework. I can´t still figure out exactly how it
>should be, so maybe I'll come up with something later.
>
>Section 5.1.2
>-------------
>I mentioned some ideas about this in the comments of section 2.1
>
>Section 5.2.2
>-------------
>All other Result-Code starts a x001, so I thought it should also starts at 2001,
>instead of 2000.
>
>Section 5.2.4
>-------------
>"...but MAY be able to satisfy the request in the future."
>What does this mean exactly? Does it mean that a server should be able to resend
>the request in a few minutes without any specific changes to the message besides
>the timestamp for example? Should it be regarded as temporary congestion? If it
>is the case, then maybe we should think of moving the
>DIAMETER_AUTHENTICATION_REJECTED and DIAMETER_CONTRACTING_AVPS to the permanent
>failure section. I think that permanent result codes should be used in the
>rejected message even if the originating server can change AVPs in the message
>which has been rejected the first time for some reasons such as unsupported
>mandatory AVPs, because it is no longer the same message anyway, and the first
>message was really considered as a permanent failure in this particular period
>of time. 
>
>Section 7.1.2
>-------------
>The 3rd paragraph should be removed.
>
>Section 10.0
>------------
>About the shared secret, maybe we should also mention that it is used by the
>Encrypted-Payload AVP?
>
>/Martin
>





From owner-aaa-bof@merit.edu  Fri Jan 19 02:49:18 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA25764
	for <aaa-archive@odin.ietf.org>; Fri, 19 Jan 2001 02:49:18 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 6BDCA5DDA1; Fri, 19 Jan 2001 02:46:17 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 556385DDDD; Fri, 19 Jan 2001 02:46:17 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by segue.merit.edu (Postfix) with ESMTP id C14395DDA1
	for <aaa-wg@merit.edu>; Fri, 19 Jan 2001 02:46:15 -0500 (EST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f0J7kFC25997
	for <aaa-wg@merit.edu>; Fri, 19 Jan 2001 08:46:15 +0100 (MET)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Fri Jan 19 08:46:59 2001 +0100
Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58)
	id <Z2G9FVHN>; Fri, 19 Jan 2001 08:46:22 +0100
Message-ID: <577066326047D41180AC00508B955DDA01D7FE5B@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Pat.Calhoun@Eng.Sun.COM'" <Pat.Calhoun@Eng.Sun.COM>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: AAA-WG: RE: Making the hard choices on AAA security
Date: Fri, 19 Jan 2001 08:46:13 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

I think that authentication on an AVP basis could be an excellent generic solution, and probably not as costly as encryption. However, should it be also allowed to authenticate a group of AVPs, since it seems that the Grouped-AVP AVP, which could contain the group ICV, is gone by now in the -18 document?

Martin

-----Original Message-----
From: Pat Calhoun [mailto:Pat.Calhoun@Eng.Sun.COM]
Sent: Thursday, January 18, 2001 7:00 PM
To: Martin Julien (ECE); Steven Glass - Solaris Software;
'stephen.farrell@baltimore.ie'
Cc: aaa-wg@merit.edu; Alain Zahm; Bernard Aboba
Subject: RE: Making the hard choices on AAA security


For proxies that wish to maintain state information, not having access
to the result code would be a problem.

Perhaps e2e authenticated, but not encrypted.

PatC
>Steven,
>
>Could we possibly think of allowing the Result-Code AVP to be encrypted for e2e,
>using the Strong Security extension of course, which would prevent proxies to
>play around with its content when not allowed by the server?
>
>Martin
>
>-----Original Message-----
>From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
>Sent: Thursday, January 18, 2001 11:16 AM
>To: Steven Glass - Solaris Software
>Cc: Bernard Aboba; Alain Zahm; aaa-wg@merit.edu
>Subject: Re: Making the hard choices on AAA security
>
>
>
>
>Steven Glass - Solaris Software wrote:
>> 
>> >
>> >
>> > > Bernard Aboba wrote:
>> > >
>> > > A proxy can change an Access-Accept into an Access-Reject under the guise
>of "policy". However, an
>> > > Access-Reject should never be changed to an Access-Accept. A good question
>is how this could be
>> > > enforced, using any of the solutions that have been proposed.
>> >
>> > Not sure it could...
>> 
>>     Maybe not from the solutions proposed...
>
>Just for clarity, CMS, Kerberos and any other self-respecting 
>e2e security solution will offer e2e data integrity. The "not 
>sure" etc. refers to allowing one type of change and 
>preventing/detecting another, not to simple integrity.
>
>Stephen.
>
>-- 
>____________________________________________________________
>Stephen Farrell         				   
>Baltimore Technologies,   tel: (direct line) +353 1 881 6716
>39 Parkgate Street,                     fax: +353 1 881 7000
>Dublin 8.                mailto:stephen.farrell@baltimore.ie
>Ireland                             http://www.baltimore.com
>




From owner-aaa-bof@merit.edu  Fri Jan 19 04:07:08 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA26316
	for <aaa-archive@odin.ietf.org>; Fri, 19 Jan 2001 04:07:08 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 0FEA65DD97; Fri, 19 Jan 2001 04:06:32 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id EC99D5DDC1; Fri, 19 Jan 2001 04:06:31 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 590FE5DD97
	for <aaa-wg@merit.edu>; Fri, 19 Jan 2001 04:06:30 -0500 (EST)
Received: from efra05-home.Germany.Sun.COM ([129.157.43.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA26614;
	Fri, 19 Jan 2001 01:06:21 -0800 (PST)
Received: from germany.sun.com (muc-isdn-15 [129.157.164.115])
	by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1) with ESMTP id KAA10532;
	Fri, 19 Jan 2001 10:06:19 +0100 (MET)
Message-ID: <3A6805FE.9B2350F@germany.sun.com>
Date: Fri, 19 Jan 2001 10:16:46 +0100
From: Erik Guttman <Erik.Guttman@germany.sun.com>
Reply-To: Erik.Guttman@sun.com
Organization: Sun Microsystems
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m)
X-Accept-Language: de-DE, fr-FR, en
MIME-Version: 1.0
To: Fredrik Johansson <fredrik.johansson@ipunplugged.com>
Cc: aaa-wg@merit.edu, erik.guttman@germany.sun.com
Subject: AAA-WG: Re: Comments on draft-calhoun-diameter-18.txt
References: <MJEMJBGGCLLDLFFAHLJKAEDJCFAA.fredrik.johansson@ipunplugged.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

> Fredrik Johansson wrote:
> 
> The <Grouped-AVP> is missing in the table in section 2.2.5

Its definition is missing too.  This is *intentional*.  Grouped-AVP
has been replaced by the Grouped value type.  This has several
advantages over a Grouped AVP.  (1) we can get rid of the 'Complex'
data type so that all AVP values are either well defined types or
a sequence of AVPs, which are themselves well defined.  (2) We do
not have open ended groups, (bags of AVPs) but rather defined 
sequences of AVPs, all of which MUST be there in the defined order.
(3) This makes it much easier to specify DIAMETER formally and to
ensure interoperability.

Erik

._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
E r i k   G u t t m a n         SHORT msgs: 01728655497@d2-message.de
Sr Staff Engineer, Sun Microsystems       Email: erik.guttman@sun.com
Eichhoelzelstr. 7, 74915 Waibstadt Germany    Phone: +49 172 865 5497



From owner-aaa-bof@merit.edu  Fri Jan 19 09:07:58 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29309
	for <aaa-archive@odin.ietf.org>; Fri, 19 Jan 2001 09:07:57 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id D987B5DE4F; Fri, 19 Jan 2001 09:07:40 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id BE2A05DE56; Fri, 19 Jan 2001 09:07:40 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by segue.merit.edu (Postfix) with ESMTP id 270345DE4F
	for <aaa-wg@merit.edu>; Fri, 19 Jan 2001 09:07:39 -0500 (EST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f0JE7CC29689
	for <aaa-wg@merit.edu>; Fri, 19 Jan 2001 15:07:12 +0100 (MET)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Fri Jan 19 15:07:07 2001 +0100
Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58)
	id <Z2G9GHL4>; Fri, 19 Jan 2001 15:07:15 +0100
Message-ID: <577066326047D41180AC00508B955DDA01D7FE60@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Pat.Calhoun@Eng.Sun.COM'" <Pat.Calhoun@Eng.Sun.COM>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>,
        "'stephen.farrell@baltimore.ie'" <stephen.farrell@baltimore.ie>
Subject: AAA-WG: RE: Making the hard choices on AAA security
Date: Fri, 19 Jan 2001 15:02:55 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA29309

Pat, Stephen,

I guess the easy answer to this is to use signed-only CMS-Data AVP, allowing the Result-Code AVP to be protected (P flag set) in the case of rejection only from a Home or Proxy server, right? Then, in the case where the Home server accept the request, the proxy could still reject it based on local policies. However, I don´t think it fits into a clean solution. Another thread in this ML talks about MRI and Result-Codes from Extension Reply/Answer, and I need to figure out where it is going before coming up with something better.

Also, if I think of an example in which the request is rejected and the Result-Code AVP authenticated by a CMS-Data AVP, I wonder if the proxy could still remove the CMS-Data AVP and replace the Result-Code AVP for a successful answer? I guess, in the case of e2e security, the originating servers should always be expecting a CMS-Data AVP from servers which are located on the other side of untrusted proxies, otherwise messages could be an indication of fraudulent activities. I think there can not be more than 1 CMS-Data AVP per message, which means that it would be difficult to mix signed-only and encrypted data. Since there is nothing in the Base and Extension protocols about it (as far as I know), maybe some clarification in the Strong Security Extension would be needed. I guess the servers need to define some special information in their routing table about trusted and untrusted servers and local policies for handling the validation of the messages. I might be missing some fundamental knowledge here, so I'd appreciate if you could answer this.

I think I understand the requirement of simplicity and lightweight... ;-)

Martin

-----Original Message-----
From: Martin Julien (ECE) [mailto:Martin.Julien@ece.ericsson.se]
Sent: Friday, January 19, 2001 8:46 AM
To: 'Pat.Calhoun@Eng.Sun.COM'; 'aaa-wg@merit.edu'
Subject: AAA-WG: RE: Making the hard choices on AAA security


I think that authentication on an AVP basis could be an excellent generic solution, and probably not as costly as encryption. However, should it be also allowed to authenticate a group of AVPs, since it seems that the Grouped-AVP AVP, which could contain the group ICV, is gone by now in the -18 document?

Martin

-----Original Message-----
From: Pat Calhoun [mailto:Pat.Calhoun@Eng.Sun.COM]
Sent: Thursday, January 18, 2001 7:00 PM
To: Martin Julien (ECE); Steven Glass - Solaris Software;
'stephen.farrell@baltimore.ie'
Cc: aaa-wg@merit.edu; Alain Zahm; Bernard Aboba
Subject: RE: Making the hard choices on AAA security


For proxies that wish to maintain state information, not having access
to the result code would be a problem.

Perhaps e2e authenticated, but not encrypted.

PatC
>Steven,
>
>Could we possibly think of allowing the Result-Code AVP to be encrypted for e2e,
>using the Strong Security extension of course, which would prevent proxies to
>play around with its content when not allowed by the server?
>
>Martin
>
>-----Original Message-----
>From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
>Sent: Thursday, January 18, 2001 11:16 AM
>To: Steven Glass - Solaris Software
>Cc: Bernard Aboba; Alain Zahm; aaa-wg@merit.edu
>Subject: Re: Making the hard choices on AAA security
>
>
>
>
>Steven Glass - Solaris Software wrote:
>> 
>> >
>> >
>> > > Bernard Aboba wrote:
>> > >
>> > > A proxy can change an Access-Accept into an Access-Reject under the guise
>of "policy". However, an
>> > > Access-Reject should never be changed to an Access-Accept. A good question
>is how this could be
>> > > enforced, using any of the solutions that have been proposed.
>> >
>> > Not sure it could...
>> 
>>     Maybe not from the solutions proposed...
>
>Just for clarity, CMS, Kerberos and any other self-respecting 
>e2e security solution will offer e2e data integrity. The "not 
>sure" etc. refers to allowing one type of change and 
>preventing/detecting another, not to simple integrity.
>
>Stephen.
>
>-- 
>____________________________________________________________
>Stephen Farrell         				   
>Baltimore Technologies,   tel: (direct line) +353 1 881 6716
>39 Parkgate Street,                     fax: +353 1 881 7000
>Dublin 8.                mailto:stephen.farrell@baltimore.ie
>Ireland                             http://www.baltimore.com
>




From owner-aaa-bof@merit.edu  Fri Jan 19 11:07:34 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01151
	for <aaa-archive@odin.ietf.org>; Fri, 19 Jan 2001 11:07:34 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 287F95DEDC; Fri, 19 Jan 2001 11:06:06 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 135EF5DDC7; Fri, 19 Jan 2001 11:06:06 -0500 (EST)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by segue.merit.edu (Postfix) with ESMTP id B82CE5DEDB
	for <aaa-wg@merit.edu>; Fri, 19 Jan 2001 11:06:04 -0500 (EST)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0JG65R14225
	for <aaa-wg@merit.edu>; Fri, 19 Jan 2001 10:06:05 -0600 (CST)
Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T5132ed48ffac12f2570b1@davir04nok.americas.nokia.com>;
 Fri, 19 Jan 2001 10:06:02 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <ZRZXN1R2>; Fri, 19 Jan 2001 10:06:02 -0600
Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B032132E9@daeis07nok>
From: Basavaraj.Patil@nokia.com
To: aaa-wg@merit.edu, diameter@diameter.org
Subject: [AAA-WG]: BURP BOF
Date: Fri, 19 Jan 2001 10:01:33 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

 

A BOF on Basic User Registration Protocol (BURP)
 
 
Charter:

The vision of pervasive computing also includes constantly being
connected and the ability to access the Internet or the enterprise
over the Internet. Mobile computing solutions based on protocols such
as Mobile IP offer seamless and continuous connectivity for
users. However a lot of roadwarriors and other types 
of users access the network from places like airports, hotels, malls
and sports complexes. These environments may offer access to the
network over wireless LANs or via Ethernet LAN ports or other
mediums. In such scenarios, 
DHCP can provide configuration information  (e.g., giving a valid
address etc.), but there is no standard way for service providers to
obtain user information to perform AAA functions. For users
who do not have Mobile IP clients on their devices but would like to
access the network, they need to register and be authenticated by the
local network service provider before being authorized to use the
resources. The intent of this proposal is to develop an application
layer registration protocol that allows a user to register in the
local network by providing identity and authentication information
to the local network which then uses a AAA infrastructure to validate
the user, charge him and, authorize use of resources. 

We would like to request a BOF on a "Basic User Registration
Protocol (BURP)" for the March 2001 meeting of the IETF in Minneapolis.
The objective of the BOF will be to  
-- Detail the scope of the proposal and applicable scenarios

-- Chart a course and an action plan (including milestones 
and deliverables) for BURP.
 
-- Investigate  the impact on existing  AAA  protocols  and  make it
flexible to support various authentication schemes.
 
The goal will be to define a standard UNI for  environments in which
neither PPP nor Mobile IP is required but AAA interaction is
essential.  The basic principle will include:
 
  -- The solution being a client-server application layer protocol
 
  -- Is applicable to both IPv4 and IPv6.
 
  -- User interacts only with a local Registration Agent (RA), which
  may reside on any node in the Network Domain.
 
  -- It should work with any configuration  protocol, such as DHCP, IPv6
  stateless autoconfiguration, and manual configuration.
 
  -- Protects RA from replay attacks.
 
  -- Provide information on and control of network usage.
 
  -- Interacts with routers/policers to limit packets forwarding based on a
  user's Service Level  Specification  (may be optional or may
  interwork with  standard policy protocols).
 
  -- Defines an RA-to-AAA interface
 
-----------------------------------------------------------------------

To subscribe to the mailing list for discussion on this topic, please
follow these instructions:

To subscribe, send mail to urp-request@research.telcordia.com, and
use "subscribe" for the subject line.

To unsubscribe, send mail to urp-request@research.telcordia.com, and
use "unsubscribe" for the subject line.

To contribute to the list, send mail to urp@research.telcordia.com.

For additional help, send mail to urp-request@research.telcordia.com
and use "help" for the subject line.

 





From owner-aaa-bof@merit.edu  Fri Jan 19 12:14:35 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02686
	for <aaa-archive@odin.ietf.org>; Fri, 19 Jan 2001 12:14:34 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 64C415DEBA; Fri, 19 Jan 2001 12:14:17 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 539BD5DEB6; Fri, 19 Jan 2001 12:14:17 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 3E07A5DEB3
	for <aaa-wg@merit.edu>; Fri, 19 Jan 2001 12:14:16 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26786;
	Fri, 19 Jan 2001 09:14:05 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA17815;
	Fri, 19 Jan 2001 09:09:59 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA12456;
	Fri, 19 Jan 2001 09:09:53 -0800 (PST)
Date: Fri, 19 Jan 2001 09:06:08 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: [AAA-WG]: RE: Self Describing record formats for multiple (non-network-acce  ss)  usage types ...
To: Abhi Deshmukh <Abhi.Deshmukh@apogeenet.com>
Cc: "'Nelson, David'" <dnelson@enterasys.com>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <B11807D7A9C5D211876B0050040549E8B16841@POSTOFFICE>
Message-ID: <Roam.SIMC.2.0.6.979923968.20123.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Just got back from out of town, so I appologize for the latency.

It is possible to make use of AAA for other accounting purposes. What I would
recommend is to come up with a set of requirements in an Internet-Draft, and
then figure out whether DIAMETER is the protocol that meets your requirements
(if memory serves, there already is an I-D on CDN accounting).

The biggest issue at that point is to find a home for this work. The AAA WG
has a fairly focused charter, and that shouldn't be changed since our work is
of high priority. Perhaps a BOF in Minn would be one alternative.

PatC
> 
> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com]
> Sent: Wednesday, January 17, 2001 3:30 PM
> To: 'aaa-wg@merit.edu'
> Subject: RE: Self Describing record formats for multiple (non-network-acce
> ss) usage types ...
> 
> >The AAA Working Group Charter states, in part: 
> >(see http://www.ietf.org/html.charters/aaa-charter.html) 
> >The Authentication, Authorization and Accounting Working Group focused on 
> >the development of requirements for Authentication, Authorization and 
> >Accounting as applied to network access. Requirements were gathered from 
> >NASREQ, MOBILE IP, and ROAMOPS Working Groups as well as TIA 45.6. 
> 
> >How do the applications you mention fit into this scope of work?  
> 
> I am trying to see if the AAA transport framework can be used to send
> accounting info (available from usage records) in a peered Content Delivery
> Network scenario (peered CDN). http://www.content-peering.org 
> 
> In particular the attributes of usage records in this case would be
> different
> than RADIUS, Mobile IP, etc. If the AAA transport can accomodate different
> record formats, then the AAA framework will be very attractive for
> *adoption* for billing systems for various services.
> 
> One way to accomodate known and unknown record formats is to have the
> payload records describe themself. This way the transport can accomodate
> *any* usage record.
> 
> I however understand the AAA framework is not meant to be all purpose. I was
> trying to see if there was a thought process along the lines of extending
> the AAA transport to accomodate "other" usage types.
> 
> Thanks for your time.
> 
> - Abhi
> 





From owner-aaa-bof@merit.edu  Fri Jan 19 13:37:55 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03953
	for <aaa-archive@odin.ietf.org>; Fri, 19 Jan 2001 13:37:55 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 521FD5DDDF; Fri, 19 Jan 2001 13:37:38 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 3E7A15DDD7; Fri, 19 Jan 2001 13:37:38 -0500 (EST)
Received: from sapphire.int.ipverse.com (w067.z208037018.sjc-ca.dsl.cnc.net [208.37.18.67])
	by segue.merit.edu (Postfix) with ESMTP id 0DA545DDAF
	for <aaa-wg@merit.edu>; Fri, 19 Jan 2001 13:37:37 -0500 (EST)
Received: from matt.ipverse.com (lsanca1-ar5-208-160.dsl.gtei.net [4.33.208.160]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id C5SX7PAT; Fri, 19 Jan 2001 10:37:35 -0800
Message-Id: <5.0.2.1.2.20010119103608.02192790@pop3.ipverse.com>
X-Sender: matt@ipverse.com@pop3.ipverse.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Fri, 19 Jan 2001 10:37:38 -0800
To: Basavaraj.Patil@nokia.com, aaa-wg@merit.edu, diameter@diameter.org
From: Matt Holdrege <matt@ipverse.com>
Subject: Re: [AAA-WG]: BURP BOF
Cc: urp@research.telcordia.com
In-Reply-To: <7B5C0390ACE7D211BC9C0008C7EABA2B032132E9@daeis07nok>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Is there some reason that the intrinsic registration method in SIP is not 
satisfactory? If there is, then you should identify it in your BOF description.


At 08:01 AM 1/19/2001, Basavaraj.Patil@nokia.com wrote:
>
>
>A BOF on Basic User Registration Protocol (BURP)
>
>
>Charter:
>
>The vision of pervasive computing also includes constantly being
>connected and the ability to access the Internet or the enterprise
>over the Internet. Mobile computing solutions based on protocols such
>as Mobile IP offer seamless and continuous connectivity for
>users. However a lot of roadwarriors and other types
>of users access the network from places like airports, hotels, malls
>and sports complexes. These environments may offer access to the
>network over wireless LANs or via Ethernet LAN ports or other
>mediums. In such scenarios,
>DHCP can provide configuration information  (e.g., giving a valid
>address etc.), but there is no standard way for service providers to
>obtain user information to perform AAA functions. For users
>who do not have Mobile IP clients on their devices but would like to
>access the network, they need to register and be authenticated by the
>local network service provider before being authorized to use the
>resources. The intent of this proposal is to develop an application
>layer registration protocol that allows a user to register in the
>local network by providing identity and authentication information
>to the local network which then uses a AAA infrastructure to validate
>the user, charge him and, authorize use of resources.
>
>We would like to request a BOF on a "Basic User Registration
>Protocol (BURP)" for the March 2001 meeting of the IETF in Minneapolis.
>The objective of the BOF will be to
>-- Detail the scope of the proposal and applicable scenarios
>
>-- Chart a course and an action plan (including milestones
>and deliverables) for BURP.
>
>-- Investigate  the impact on existing  AAA  protocols  and  make it
>flexible to support various authentication schemes.
>
>The goal will be to define a standard UNI for  environments in which
>neither PPP nor Mobile IP is required but AAA interaction is
>essential.  The basic principle will include:
>
>   -- The solution being a client-server application layer protocol
>
>   -- Is applicable to both IPv4 and IPv6.
>
>   -- User interacts only with a local Registration Agent (RA), which
>   may reside on any node in the Network Domain.
>
>   -- It should work with any configuration  protocol, such as DHCP, IPv6
>   stateless autoconfiguration, and manual configuration.
>
>   -- Protects RA from replay attacks.
>
>   -- Provide information on and control of network usage.
>
>   -- Interacts with routers/policers to limit packets forwarding based on a
>   user's Service Level  Specification  (may be optional or may
>   interwork with  standard policy protocols).
>
>   -- Defines an RA-to-AAA interface
>
>-----------------------------------------------------------------------
>
>To subscribe to the mailing list for discussion on this topic, please
>follow these instructions:
>
>To subscribe, send mail to urp-request@research.telcordia.com, and
>use "subscribe" for the subject line.
>
>To unsubscribe, send mail to urp-request@research.telcordia.com, and
>use "unsubscribe" for the subject line.
>
>To contribute to the list, send mail to urp@research.telcordia.com.
>
>For additional help, send mail to urp-request@research.telcordia.com
>and use "help" for the subject line.
>
>




From owner-aaa-bof@merit.edu  Fri Jan 19 15:57:49 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06255
	for <aaa-archive@odin.ietf.org>; Fri, 19 Jan 2001 15:57:49 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 6EDB05DDC7; Fri, 19 Jan 2001 15:57:29 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 5E2385DDB2; Fri, 19 Jan 2001 15:57:29 -0500 (EST)
Received: from gate.internaut.com (unknown [64.38.134.108])
	by segue.merit.edu (Postfix) with ESMTP id C6F5C5DDAF
	for <aaa-wg@merit.edu>; Fri, 19 Jan 2001 15:57:27 -0500 (EST)
Received: from e1kj2 (kidneybean [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0JKrCR17608;
	Fri, 19 Jan 2001 12:53:12 -0800
From: "Bernard Aboba" <aboba@internaut.com>
To: <Abhi.Deshmukh@apogeenet.com>
Cc: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: [AAA-WG]: Re: Self Describing record formats for multiple (non-network-access) usage types 
Date: Fri, 19 Jan 2001 12:57:06 -0800
Message-ID: <OJEJKOMOEAKLMOILFCPJOEBIDPAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>I have been looking at the AAA related documents for record formats and I
>have an idea to share about the formats.

Do you have an idea to share relating to defining a record format, or
relating to carriage of a record format?

>Is there a thought in the AAA WG of having self describing records in the
>overall AAA framework ?.

At one point, there was discussion of using DIAMETER for carriage of
record formats, rather than just AVPs. However, for the goals of the
AAA WG, this did not seem essential, and so the WG consensus has been
to remove support for the ADIF record format from the protocol.

>This would allow other known unknown and not invented usage records to be
>accomodated in the AAA framework.

There are many ways to transport record formats. To figure out which one
of them is useful, you need to have a requirements document laying out
what the transport has to do.

>This way, if the transport issues are resolved, new usage types would not
present a
>challenge to the record format. Also having a AAA framework that
accomodates
>other usage types (other than end user network access) would be beneficial.

Transport issues are in practice the crux of the problem. You have to think
about what kinds of security you need to provide, how reliable the transport
needs to be, etc. Once you've got that all figured out, then you have a way
of deciding if DIAMETER is right for you.

>I have some ideas on this thought process. If this thought is-being or
>has-been dicussed, then perhaps I missed it. Is there any place that I
>should be looking ? Any useful pointers ?

I'd suggest looking at the following documents:
http://www.ietf.org/rfc/rfc2924.txt
http://www.ietf.org/rfc/rfc2975.txt
http://www.ietf.org/internet-drafts/draft-aboba-roamops-adif-00.txt (just
submitted)




From owner-aaa-bof@merit.edu  Fri Jan 19 16:19:25 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06502
	for <aaa-archive@odin.ietf.org>; Fri, 19 Jan 2001 16:19:24 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 280125DEA2; Fri, 19 Jan 2001 16:16:48 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 164205DE75; Fri, 19 Jan 2001 16:16:48 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id B19C35DDAF
	for <aaa-wg@merit.edu>; Fri, 19 Jan 2001 16:16:46 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05340;
	Fri, 19 Jan 2001 13:16:45 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA18652;
	Fri, 19 Jan 2001 13:16:44 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA17951;
	Fri, 19 Jan 2001 13:16:42 -0800 (PST)
Date: Fri, 19 Jan 2001 13:12:58 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1)" draft / Minor Comments
To: Bob Kopacz <BKopacz@InterlinkNetworks.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>, Aaa-Wg <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <NEBBKEONLKEDJCMHGHPIMEHECAAA.BKopacz@InterlinkNetworks.com>
Message-ID: <Roam.SIMC.2.0.6.979938778.19639.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Bob,

Thanks for taking the time to review the I-D and providing great feedback. My
responses are inline below.

PatC

> Hi Pat,
> 
> Here's some further minor comments on the "DIAMETER Base
> Protocol (Alpha 1)" draft.
> 
> 
> Section 2.2.4.1 Example AVP with a Grouped value type
> --------------------------------------------------------
> 
> This section gives an example of a Grouped-AVP which includes
> the User-Name AVP and the Host-IP-Address AVP.  Since the
> Host-IP-Address AVP is only present in the DRI packet
> (according to section 2.5.4 Host-IP-Address AVP), and since
> User-Name cannot be present in a DRI, maybe the example should
> be revamped to a non-conflicting group of AVPs.

Yes, good catch. Eliminating the User-Name AVP fixes the problem.

> 
> 
> Section 2.3.1 "Host-Name AVP"
> -----------------------------
> 
> The Host-Name AVP defines the value as being the "sender's"
> identity, and later as the identity of the "originator" of the
> Diameter message.
> 
> One could, like I did, interpret "sender" and "originator" as
> the peer who sent this packet, treating Host-Name AVP as a
> "Peer-Name" AVP, where each server in a proxy chain replaced the
> AVP value with his name.
> 
> But the Host-Name seems to identify the original sender and
> not necessarily the immediate sender which may be a proxy.  This
> might be stated explicitly, else a proxy implementation may
> replace the Host-Name AVP from a received packet with a
> Host-Name AVP identifying himself, before forwarding the packet
> to the next hop Diameter server.
> 
> Maybe some explicit clarifying text could be added, e.g:
> 
>     "This AVP identifies the endpoint which originated the 
>     Diameter message, i.e. the NAS, home server, or broker.  
>     Proxy servers do not modify this AVP".

Fixed (and thanks for the text!)

> 
> 
> 3.1  Session-Id AVP
> -------------------
> 
> An email (not mine) from a while back asked some questions about
> the Session-ID AVP, i.e. "How is this encoded? All ASCII? A mix
> of null-terminated strings and numbers in network byte order?
> Something else?"
> 
> I think the answer was all ASCII, in network byte order, but
> this hasn't made its way into the document.

check, now specifies UTF-8 encoding.

> 
> 
> Section 8.4
> ------------
> 
> Section 8.4 is inconsistent with section 5.2.  Section 8.4
> states: 
> 
>    As defined in Section 5.2, the Result Code AVP (AVP Code 268) defines
>    the values 0-8. ...
> 
> The values defined in section 5.2 are no longer 0-8.

wow... can't believe I missed that one.

> 
> 
> Minor Typos/etc:
> ----------------
again, thanks for these as well.





From owner-aaa-bof@merit.edu  Fri Jan 19 16:38:22 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06715
	for <aaa-archive@odin.ietf.org>; Fri, 19 Jan 2001 16:38:21 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id DB92C5DDC6; Fri, 19 Jan 2001 16:38:03 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id C9A365DDB2; Fri, 19 Jan 2001 16:38:03 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id A466B5DDAF
	for <aaa-wg@merit.edu>; Fri, 19 Jan 2001 16:38:02 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20565;
	Fri, 19 Jan 2001 13:38:00 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA23399;
	Fri, 19 Jan 2001 13:38:00 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA18434;
	Fri, 19 Jan 2001 13:37:33 -0800 (PST)
Date: Fri, 19 Jan 2001 13:33:49 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: [AAA-WG]: Re: DIAMETER Base Protocol (18-Alpha 1)" draft / 5.0 Error Reporting
To: Bob Kopacz <BKopacz@InterlinkNetworks.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>, Aaa-Wg <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <NEBBKEONLKEDJCMHGHPIEEHFCAAA.BKopacz@InterlinkNetworks.com>
Message-ID: <Roam.SIMC.2.0.6.979940029.703.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Hi Pat,
> 
> When reading section 5.0 "Error Reporting" in the "DIAMETER Base
> Protocol (Alpha 1)" draft, I came up with a number of questions
> about the handling of a bad reply message, which probably means
> I'm missing something basic.
> 
> Maybe some clarifications could be added to this section.

I would not be surprised that some clarifications are required.

> 
> I fear I'm all wet here, but here's some questions:
> 
> 
> Case 1:  NAS -> HomeServer.  NAS detects error.
> -----------------------------------------------
> 
> We have a NAS talking directly to his Home Server; no proxies
> are involved.  The NAS originates a valid *-Request.  The
> HomeServer sends a positive *-Answer which the NAS considers
> erroneous (e.g. the *-Answer packet is syntactically incorrect;
> or the *-Answer packet is syntactically correct but contains an
> AVP with an inappropriate value).
> 
> I assume that an MRI is intended as a response not just to bad
> *-Request and *-Ind packets, but also to bad *-Answer packets.

correct.

> 
> The NAS, I think, would send an MRI back to the home server with
> an appropriate Result-Code.  If the MRI serves no other purpose,
> it can at least make its way into the home server's log file, as
> an aid to those investigating why sessions aren't being set up.
correct. Also keep in mind that Dave Mitton also suggested adding a third
message to "ack" the reply. This is not something that we've ever discussed
in the DIAMETER list, but we should also consider such a scheme.

> 
> If the home server maintains session state, he considers this to
> be an active session, since he sent a positive reply.  Is the
> MRI sufficient to stimulate the home server to release this
> active session, or should the NAS also (or instead) send a
> Session-Terminate-Request?  (The MRI may not contain enough
> information for the home server to make a determination as to
> the fate of this session.  For example, if the MRI was in
> response to the home server's positive AA-Answer, the home
> server can release the session.  If the MRI was in response to
> the home server's Session-Terminate-Ind, then the home server
> wouldn't release the session.  But the MRI doesn't indicate the
> home server's offending packet.  The home server also doesn't 
> know if the Identifier value is his or the NAS's).
> 
> According to the table in section 5.0, an MRI can be sent only
> if the error is of type "Unknown Command".  If so, what can the
> NAS send to the Home Server if the error is of type "Unknown
> AVP", "Bad AVP Value", or "Extension Error"? According to the
> table, the NAS should send some extension-specific error
> response, but I don't see any candidates that can be sent in
> response to a bad reply.

So the spirit of the draft is that if there are no appropriate message
to be sent to return an error, an MRI is used. Again, see my above on
Dave's proposal, which would solve this problem in a cleaner way.

> 
> Does the NAS behave differently if he receives a bad negative
> reply rather than a bad positive reply? (e.g. forego sending the
> MRI)

Good question. Ideally, an MRI would be similar to how ICMP works, but I am
not sure that this solves all problems. So, if the above example were used
the MRI would have to be used as a real response to a reply.

Now I am even more convinced that Dave had a great idea.

> 
> 
> Case 2:  NAS -> RoutingProxy -> HomeServer.  NAS detects error.
> ---------------------------------------------------------------
> 
> Same as case 1, but with a proxy in the middle: The NAS
> originates a valid *-Request.  The HomeServer sends a positive
> *-Answer, which passes through the proxy ok, but which the NAS
> considers erroneous.
> 
> Assuming the NAS sent an MRI, what does the proxy do with it?
> 
> It seems like the proxy would want to route the MRI to the home
> server, since the MRI was most likely a response to something
> the home server sent, and not to something the proxy sent (the
> proxy likely couldn't determine who was at fault anyway, so
> would just forward the MRI in all cases and let the humans
> figure out what went wrong).
> 
> However, if the proxy routes on Extension Id, he may be unable
> to route the MRI, which lacks identification of the offending
> extension. (I'm referring to Section 6.2.1 "Proxy and Redirect
> Server handling of requests", which says "It is possible for a
> routing entry to have a different destination based on the
> extension identifier of the message. This field is typically
> used as a secondary key field in routing table lookups.").
> 
> Here's a thought: Rename the Unrecognized-Command-Code AVP to
> the "Failed-Command-Code AVP", and change its value to
> contain the Command Code that was being processed when the error
> was detected, be it recognized or not.  Include this new AVP in
> all MRI messages.  The Result-Code value tells you if the
> command was unrecognized.  This seems useful when debugging and
> tracing.  And in this case the proxy can now determine the
> extension of the offending packet and route the NAS's MRI
> accordingly.

Very good suggestion. It requires minimal changes, and solves a
real problem.

> 
> 
> Case 3:  NAS -> RoutingProxy -> HomeServer.  PROXY detects error.
> -----------------------------------------------------------------
> 
> Similar to case 1, but with a proxy in the middle: The NAS
> originates a valid *-Request.  The HomeServer sends a positive
> *-Answer which the PROXY considers erroneous.
> 
> Here the proxy might want to generate two messages, one to the
> NAS and one to the home server.  The proxy would do what the NAS
> would do in Case 2: send an MRI to the home server.  The proxy
> would turn the home server's positive answer into a negative
> answer, replace the Result-Code AVP, and send it on to the NAS.

I am not sure that I really like this. This just really stresses the need
for the three way message (of type -Ind, I would think). This would allow
the NAS to send it, and indicate whether an error had been added by
a middle proxy, or if it didn't like the message.

This seems to keep the proxies as dumb as we can.

> 
> When the NAS receives a negative reply to some request, there is
> a Result-Code AVP which indicates the error, but there isn't an
> indication of who originally generated the error, i.e. some
> proxy along the path, or the home server.
> 
> It would be useful to know which machine originated the negative
> Result-Code AVP.  It most cases this is indicated by the
> Host-Name AVP, but in this case the Host-Name is the home server
> while the proxy detected the error.
> 
> So a new "Error-Detecting-Server-Name" AVP (not a good name)
> could be useful.  The AVP would contain the name of the machine
> which originated the failure Reply-Code value, useful in tracing
> and debugging.  This new AVP immediately points the technical
> staff to the offended (possibly misconfigured) server.

hmmm... someone brought up the point of how to identify the server that
set the Result-Code AVP. Again, I think that this is a great suggestion
and will include it, since it solves a real problem.

> 
> Also, if the NAS knew that a negative answer came from some
> proxy, he might try a different route to the home server;
> but if the home server originated the reject, well then give up.
> 
> If the proxy receives a flawed negative reply from the home
> server, rather than a flawed positive reply, does he act
> differently?  For example, only override the home server's
> Result-Code value if it was 2xxx SUCCESS; forego sending the MRI
> to the home server.

Well, see my comment above on the proxy sending MRIs, but I agree that if an
error is already set, further proxies MUST NOT change the value, and simply 
treat it as a failed request.

> 
> 
> Out-of-Range Result-Code values:
> --------------------------------
> 
> Section 5.2 "Result-Code AVP" defines classes of error codes in
> the range 1xxx-5xxx.  
> 
> What does a receiver do when receiving a Result-Code value
> outside of the defined ranges?
> 
> I'm guessing an out-of-range Result-Code value would be treated
> as a 5xxx (Permanent failure).  Should an MRI or error log entry
> be generated?  
This is probably a good assumption, and I will add clarifications to the text.

> Should a Result-Code value of zero be treated as
> a 2xxx (Success) for compatibility with existing Diameter
> implementations?
I do not think this is necessary.

PatC




From owner-aaa-bof@merit.edu  Fri Jan 19 16:53:15 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06958
	for <aaa-archive@odin.ietf.org>; Fri, 19 Jan 2001 16:53:14 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 1145D5DDAF; Fri, 19 Jan 2001 16:53:00 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id ABD6D5DDB2; Fri, 19 Jan 2001 16:52:59 -0500 (EST)
Received: from rock2 (rock2.apogeenet.com [63.119.238.75])
	by segue.merit.edu (Postfix) with ESMTP id CD97D5DDAF
	for <aaa-wg@merit.edu>; Fri, 19 Jan 2001 16:52:57 -0500 (EST)
Received: from postoffice.apogeenet.com ([10.30.0.90])
	by rock2 (8.10.0/8.10.0) with ESMTP id f0JLk3v06308;
	Fri, 19 Jan 2001 16:46:18 -0500 (EST)
Received: by postoffice.apogeenet.com with Internet Mail Service (5.5.2650.21)
	id <D10D64KG>; Fri, 19 Jan 2001 16:48:00 -0500
Message-ID: <B11807D7A9C5D211876B0050040549E8B1685A@postoffice.apogeenet.com>
From: Abhi Deshmukh <Abhi.Deshmukh@apogeenet.com>
To: "'Bernard Aboba'" <aboba@internaut.com>,
        Abhi Deshmukh <Abhi.Deshmukh@apogeenet.com>
Cc: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: [AAA-WG]: An idea on Self describing accounting streams .....
Date: Fri, 19 Jan 2001 16:47:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> From: Bernard Aboba [mailto:aboba@internaut.com]
>Subject: [AAA-WG]: Re: Self Describing record formats for multiple
>(non-network-access) usage types 

> Do you have an idea to share relating to defining a record format, or
> relating to carriage of a record format?

The main idea is to accommodate *any* usage type for *any* kind of service. 
If the transfer mechanism is agnostic of the attributes and format of the
usage record, then  this allows the transfer to be extensible and attractive
for wide adoption.

Let me know what you think. 

- Abhi

Here is the basic idea on self describing accounting streams:

0. A receiver would connect to the sender. This would include some
sort of authentication.

1. Sender sends structure of information that it wishes to sends
So for example if it wanted to send Web usage information,
It would say, "I have four fields to send"
the first field is a long that means the end user's IP address
the second field is a string that means the URL that was accessed
the third field is a long64 that means number of bytes accessed
the fourth field is a timestamp that means the time this URL was accessed.

The meaning is encoded in a number and is called a catalog.
There are many such catalog ids (hundreds) available to mean different
things like packets,
sessions, whether cached, and so on

This is almost like a binary DTD for an XML document.

2. Receiver accepts the structure and sends an ack to the sender

3. From this point on the sender can send the accounting usage records
according
to the format specified in 1 and acked in 2. 

4. For efficiency, the structure of Information may not be duplicated in
each accounting payload packet.

5. I have some extensions to the above idea for 
	a. filters - If a receiver is interested in a subset of data, then
it can send a filter spec - this allows the sender to send only information
that receiver is interested in, saving bandwidth.
      b. fault-tolerance - Handle failure in sender and receiver
	c  load-balancing - Have multiple receivers load balance a single
stream of accounting info

6. A sender could be sending accounting streams to many receivers.

7. I have done some dry runs on many usage types include Web services,
Caching services, and others and I have been able to use the above idea with
all of them.

8. The underlying transport could be TCP or UDP.

9. Streams could be compressed using standard compression algorithms.

10. Encryption of usage records could also be supported.

11.  Personally I prefer tunneling encrypted/compressed records on top of
HTTP - this allows flexibility in transfer through firewalls on the
public/private network.

- Abhi

-----Original Message-----
From: Bernard Aboba [mailto:aboba@internaut.com]
Sent: Friday, January 19, 2001 3:57 PM
To: Abhi.Deshmukh@apogeenet.com
Cc: Aaa-Wg@Merit. Edu
Subject: [AAA-WG]: Re: Self Describing record formats for multiple
(non-network-access) usage types 


>I have been looking at the AAA related documents for record formats and I
>have an idea to share about the formats.

Do you have an idea to share relating to defining a record format, or
relating to carriage of a record format?

>Is there a thought in the AAA WG of having self describing records in the
>overall AAA framework ?.

At one point, there was discussion of using DIAMETER for carriage of
record formats, rather than just AVPs. However, for the goals of the
AAA WG, this did not seem essential, and so the WG consensus has been
to remove support for the ADIF record format from the protocol.

>This would allow other known unknown and not invented usage records to be
>accomodated in the AAA framework.

There are many ways to transport record formats. To figure out which one
of them is useful, you need to have a requirements document laying out
what the transport has to do.

>This way, if the transport issues are resolved, new usage types would not
present a
>challenge to the record format. Also having a AAA framework that
accomodates
>other usage types (other than end user network access) would be beneficial.

Transport issues are in practice the crux of the problem. You have to think
about what kinds of security you need to provide, how reliable the transport
needs to be, etc. Once you've got that all figured out, then you have a way
of deciding if DIAMETER is right for you.

>I have some ideas on this thought process. If this thought is-being or
>has-been dicussed, then perhaps I missed it. Is there any place that I
>should be looking ? Any useful pointers ?

I'd suggest looking at the following documents:
http://www.ietf.org/rfc/rfc2924.txt
http://www.ietf.org/rfc/rfc2975.txt
http://www.ietf.org/internet-drafts/draft-aboba-roamops-adif-00.txt (just
submitted)




From owner-aaa-bof@merit.edu  Fri Jan 19 16:57:09 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07016
	for <aaa-archive@odin.ietf.org>; Fri, 19 Jan 2001 16:57:08 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 782475DDD7; Fri, 19 Jan 2001 16:56:51 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 6814B5DDD1; Fri, 19 Jan 2001 16:56:51 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 2C5915DDB2
	for <aaa-wg@merit.edu>; Fri, 19 Jan 2001 16:56:50 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03875;
	Fri, 19 Jan 2001 13:56:44 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA02665;
	Fri, 19 Jan 2001 13:56:44 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA18832;
	Fri, 19 Jan 2001 13:56:41 -0800 (PST)
Date: Fri, 19 Jan 2001 13:52:53 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: [AAA-WG]: Re: Comments on draft-calhoun-diameter-18.txt
To: Tony Johansson <tony.johansson@ericsson.com>
Cc: Pat.Calhoun@eng.sun.com, AAA Listan <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <3A65F9EB.39C1004C@ericsson.com>
Message-ID: <Roam.SIMC.2.0.6.979941173.13865.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Hi Pat,
> 
> I think this one starts to look really good, just a couple of comments.
> 
> section 2.4 State Machine, page 16:
> 
> I think the typo is made on the second  row from the top (this has been sent
> earlier on the list by some one else): New State should be Wait-DRI not Open.
>  >>>>>
> State     Event                          Action    New State
> -----     -----                          ------    ---------
> ...
> 
> Initial   Receive transport level        Send DRI  Open
>           connection request from a
>           DIAMETER peer.
> 
> Should be:
> <<<<<<
> State     Event                          Action    New State
> -----     -----                          ------    ---------
> ...
> 
> Initial   Receive transport level        Send DRI  Wait-DRI
>           connection request from a
>           DIAMETER peer.

hmmm.... I could have sworn that I fixed this problem, but apparently not :(

> 
> Section 6.7 Loop Detection, page 30:
> 
> It is clear that you should reply with an Answer on Request and a Reply on a
> Query with the Result-Code AVP set to DIAMETER_LOOP_DETECTED, but what about
> an Indication? To me the most logical thing would be to send back an MRI. Is
> that the right assumption...

Correct. Section 5.1 states that the MRI is to be sent when:

2. An error is found in a message for which there is no appropriate
response.

PatC




From owner-aaa-bof@merit.edu  Fri Jan 19 17:07:31 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07166
	for <aaa-archive@odin.ietf.org>; Fri, 19 Jan 2001 17:07:31 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 99E865DED7; Fri, 19 Jan 2001 17:05:15 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 80EB75DEF2; Fri, 19 Jan 2001 17:05:15 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 4113E5DED7
	for <aaa-wg@merit.edu>; Fri, 19 Jan 2001 17:05:14 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09675;
	Fri, 19 Jan 2001 14:05:12 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA05135;
	Fri, 19 Jan 2001 14:05:08 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA18942;
	Fri, 19 Jan 2001 14:05:04 -0800 (PST)
Date: Fri, 19 Jan 2001 14:01:20 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: [AAA-WG]: Re: DIAMETER Base Protocol (18-Alpha 1) draft / Identifier
To: Bob Kopacz <BKopacz@InterlinkNetworks.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>, Aaa-Wg <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <NEBBKEONLKEDJCMHGHPIOEHICAAA.BKopacz@InterlinkNetworks.com>
Message-ID: <Roam.SIMC.2.0.6.979941680.9138.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Hi Pat,
> 
> Dave Spence passed me some notes he had made some time back,
> suggesting that the references the Identifier field could be
> clarified.
> 
> Here is my take on Dave's suggestions:
> 
> - - -
> 
> Here's what Diameter-18 (Alpha 1) has to say:
> 
>   Identifier
>     The Identifier field is four octets, and aids in matching
>     requests and replies. The sender MUST ensure that the identifier
>     in a message is locally unique (to the sender) at any given
>     time, and MAY attempt to ensure that the number is unique across
>     reboots. The identifier is normally a monotonically increasing
>     number, whose start value was randomly generated. DIAMETER
>     servers should consider a message to be unique by examining the
>     source address, source port, Session-Id and Identifier field of
>     the message.
> 
> 
> Suggestion: Distinguish between the requirement for the Identifier 
> field in request messages versus reply messages.
> 
> Discussion: The first sentence of Diameter-18 says that the
> Identifier field aids in matching requests and replies.  The second
> sentence says that the sender MUST ensure that the identifier in a
> message is locally unique (to the sender).  But this second
> statement only applies to requests.  It is incorrect for responses.
> For responses, the Identifier should presumably be copied from the
> Identifier field of the corresponding request.  That isn't stated
> here, and not all of the specific response specifications state this
> either.

Correct, I will fix the text.

> Suggestion: Indicate that a proxy is required to manufacture his own
> Identifier value when forwarding a request, and is required to
> replace the originally received Identifier when returning a
> response.
> 
> Discussion: As to the Identifier being unique with respect to the
> sender, the fourth sentence of Diameter-18 clarifies that "sender"
> means "source address and source port".  This implies that the proxy
> should overwrite the value of the Identifier field when forwarding.  
> 
> Now that responses need to be returned back down the request path
> but in reverse (NAI-based message routing by proxies was removed
> between diameter-17 and diameter-18), having the proxies change the
> Identifier field will help them match responses to requests.  State
> stored in the proxy or in the Proxy-State AVP can be used to
> correctly replace the Identifier field as the response is returned
> back down the chain.  
> 
> All this mechanism should be specified in the protocol.

Yes, I do agree, and this text belongs somewhere in section 6, where proxying
is discussed.

> 
> - - -
> 
> 
> Historical note-- 
> 
>     draft-calhoun-diameter-17.txt gave routing proxies the option of
> NAI-based message routing, which allowed a response to be returned
> through a different path.  This meant that a routing proxy, when
> forwarding a request, could not meet the requirements, whether he
> overwrote the originally received Identifier or not. (!)
> 
>     When returning the response through a different proxy,
> overwriting the value of the Identifier field by a proxy in the
> Request path could result in cases where the NAS receives a response
> whose Identifier does not match that sent in the NAS's request.
> 
>     Firstly, The overwritten Identifier field would not help the
> proxy receiving the response at all, but presumably it doesn't
> need to be helped because any state it needs will not be in its
> memory but must be retrieved from the Proxy-State AVP (which
> must have the format it expects).  
> 
>     Secondly, there may be more than one proxy in the chain, and
> different numbers of proxies on the way out than on the way back.
> Then the "send it back a different way" mechanism is broken.  There
> is just no way to get the Identifier field right in the copy of the
> response that gets sent to the NAS.  So in that case, the right
> thing to do would have been for proxies not to change the Identifier
> field.  But this violates the sender's unique-Identifier requirement.
> 
yes, I agree that proxies would not be able to change the Identifier field if
the reverse path was different. Since this is no longer supported (to simplify
the protocol), this problem no longer exists.

Thanks to you and Dave for pointing this out.

PatC




From owner-aaa-bof@merit.edu  Fri Jan 19 17:34:06 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07328
	for <aaa-archive@odin.ietf.org>; Fri, 19 Jan 2001 17:34:05 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 82A2F5DDE1; Fri, 19 Jan 2001 17:32:30 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 6E1035DEC4; Fri, 19 Jan 2001 17:32:30 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 55F065DDE1
	for <aaa-wg@merit.edu>; Fri, 19 Jan 2001 17:32:29 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26830;
	Fri, 19 Jan 2001 14:32:27 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA25693;
	Fri, 19 Jan 2001 14:32:25 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA24413;
	Fri, 19 Jan 2001 14:32:24 -0800 (PST)
Date: Fri, 19 Jan 2001 14:28:40 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Cc: "'Pat.Calhoun@Eng.Sun.COM'" <Pat.Calhoun@eng.sun.com>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FE56@eestqnt104.es.eu.ericsson.se>
Message-ID: <Roam.SIMC.2.0.6.979943320.2302.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id RAA07328

> Here is a small contribution to your document, which I think is basically a
> great piece of work for DIAMETER. 

Thanks, and I appreciate the comments below. Please see my comments inline.

PatC

> 
> 
> Section 1.0
> -----------
> In the second last paragraph, we have:
> "Given that the server MAY send unsocilited messages to clients, it is
> possible for the server to also issue authentication requests." Shouldn't it
> be AA-Challenge-Ind instead of authentication requests?
> 
> Should we make this document as independant as possible from the extension
> specifics, or do we want to keep this close relationship between the base
> and extension protocols? The thing is that we often read about
> authentication messages and so on in this document, which I don't think
> really belong here, right? Instead, this document should specify something
> as generic as a framework offering sessions in the implementing servers with
> certain APIs and caracteristics. What do you think? 

Correct, and perhaps the quote paragraph needs to be changed to exclude
references to authentication requests. The individual extensions should
concern themselves with such text.

If we agree on this, then I believe it does provide a better framework, and
less coupling.

Comments?

> 
> Section 2.0 - par.5
> -------------------
> "Session state (associated with a Session-Id) MUST be freed upon receipt of
> the Session-Termination-Request, Session-Termination-Answer, expiration of
> authorized service time in the Session-Timeout AVP, and according to rules
> established in a particular extension/application of DIAMETER."
> 
> I think this sentence is confusing me. Are you trying to show the real
> trigger for the session release, the STR (as in section 3.5.2), or the
> reasons why an STR could have been sent? It seems to me that the
> "Session-Termination-Answer, expiration of authorized service time in the
> Session-Timeout AVP, and according to rules established in a particular
> extension/application of DIAMETER." part is more related to original reasons
> why an STR has been sent. Also, it is confusing to read "authorized service
> time in the Session-Timeout AVP" when you can also refer to the reason that
> the "authorization-lifetime-AVP" might have time-out as well, which I assume
> would trigger an STR. I need more info from you if you want me to propose
> something else.

I think that the confusion is largely in the quoted text. What the above
attempts to state is that servers that maintain state needs to relinquish such
state when: 1. A Session-Termination-Request is received,
2. A Session-Termination-Answer is received,
3. The session has timed out (which does NOT require sending any termination 
   messages), or
4. Any other rules specified in extensions.

Does this help? If so, I can itemize each condition in the draft. I think this
would read better anyway.

> 
> Section 2.1
> -----------
> While looking at the DIAMETER header format, it came to me that it might be
> cleaner to put the Vendor-ID before the Command-Code, since the Command-Code
> is worthless without the Vendor-ID and finding it first would make more
> sense. And then I thought, since we might remove the PCC and add more flags,
> shouldn't we add a flag indicating if a Vendor-ID is present at all in the
> message, just like in the AVP header? And since we are there, maybe we could
> put a 2 bit indicator (0: Base protocol, 1: Extension-ID, 2: Vendor-ID, 3:
> reserved) for the Extension-ID or Vendor-ID when present in the message
> (referring to ML on "Capabilities Negotiation and proxies"), which then
> would mean that the command-code is per Extension-ID and Vendor-ID base,
> completely independent of the Base protocol command-code. Maybe an AVP for
> the command-code field would be a better idea, because it could include the
> indicator bits and also could be used in a MRI in the Failed-AVP AVP, making
> obsolete the Un! recognized-Command-Code AVP which lacks the information on
> the Vendor-ID AVP and Extension-ID. 

hmmm... This is a good comment, but I would like to solicit comments from
other DIAMETER developers (and other people that also generally care). 

For this reason I am also adding the diameter mailing list,

> 
> Section 2.2.3 - par.1
> ---------------------
> "... seven data types" should be replaced with "the following data types",
> since we actually have 10 and it might keep changing.

yes, good suggestion.

> 
> Section 2.2.5
> -------------
> It would be more useful, at least for me, to have a list of attributes
> sorted by name, instead AVP codes, which are meaningless to human normal
> reading.

that works for me. Anyone object?

> 
> Section 2.5 - par.1
> -------------------
> "...the Device-Reboot-Ind message MUST contain one Host-IP-Address AVP for
> each potential IP address that MAY be locally used when transmitting
> DIAMETER messages."
> 
> Please, could you tell me briefly why we need to send all IP addresses of
> the device? I guess it is because the device is not registered into a DNS
> and we want to build an internal DNS inside the DIAMETER server along with
> the Host-Name AVP for message routing, right? Should we have a dynamic or
> static DNS in the server?

It was intended to fully support SCTP, which inherently supports multi-homed
servers.

> 
> And referring to ML "Re: DIAMETER Base Protocol (Alpha 1)/2.5.1 Vendor-Name
> AVP", I also don´t quite see the purpose of the Vendor-Name AVP instead of
> the Vendor-ID AVP in the DRI. 

So, if I understand, you are arguing in favor of the Vendor-ID, correct? Any
objections?

> 
> Section 5.0
> -----------
> The list of Error Types is a bit confusing with the one found in section 5.1
> for MRI. I think it needs some rework. I can´t still figure out exactly how
> it should be, so maybe I'll come up with something later.

Are the classes what you find troubling?

> 
> Section 5.1.2
> -------------
> I mentioned some ideas about this in the comments of section 2.1
> 
> Section 5.2.2
> -------------
> All other Result-Code starts a x001, so I thought it should also starts at
> 2001, instead of 2000.

ok... consistency is good.

> 
> Section 5.2.4
> -------------
> "...but MAY be able to satisfy the request in the future."
> What does this mean exactly? Does it mean that a server should be able to
> resend the request in a few minutes without any specific changes to the
> message besides the timestamp for example? Should it be regarded as
> temporary congestion? 

It is intended to contain errors that occur due to some temporary condition,
and the request can be tried again later. I am not sure how to express
"future". A timestamp may not really help, since the server may not know when
the administrator will free up some disk space (as an example).

> If it is the case, then maybe we should think of
> moving the DIAMETER_AUTHENTICATION_REJECTED and DIAMETER_CONTRACTING_AVPS to
> the permanent failure section. I think that permanent result codes should be
> used in the rejected message even if the originating server can change AVPs
> in the message which has been rejected the first time for some reasons such
> as unsupported mandatory AVPs, because it is no longer the same message
> anyway, and the first message was really considered as a permanent failure
> in this particular period of time. 
yes, you are right. I will move these.

> 
> Section 7.1.2
> -------------
> The 3rd paragraph should be removed.

that darned cut and paste problem again :)

> 
> Section 10.0
> ------------
> About the shared secret, maybe we should also mention that it is used by the
> Encrypted-Payload AVP?
Absolutely.

Again, great comments. Looking forward to continuing some of these topics...




From owner-aaa-bof@merit.edu  Fri Jan 19 17:37:06 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07374
	for <aaa-archive@odin.ietf.org>; Fri, 19 Jan 2001 17:37:06 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 7E7145DDF4; Fri, 19 Jan 2001 17:36:33 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 6D3215DDD1; Fri, 19 Jan 2001 17:36:33 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 2E2255DDB2
	for <aaa-wg@merit.edu>; Fri, 19 Jan 2001 17:36:32 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29577;
	Fri, 19 Jan 2001 14:36:28 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA27091;
	Fri, 19 Jan 2001 14:36:27 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA24480;
	Fri, 19 Jan 2001 14:36:06 -0800 (PST)
Date: Fri, 19 Jan 2001 14:32:12 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: [AAA-WG]: Re: Comments on draft-calhoun-diameter-18.txt
To: Fredrik Johansson <fredrik.johansson@ipunplugged.com>
Cc: AAA Listan <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <MJEMJBGGCLLDLFFAHLJKAEDJCFAA.fredrik.johansson@ipunplugged.com>
Message-ID: <Roam.SIMC.2.0.6.979943532.7993.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> The <Grouped-AVP> is missing in the table in section 2.2.5
> 
I think Erik addressed this one, but I am no longer sure. Grouped is now a
data type, much like Unsigned32 and OctetString. So, AVPs MAY be of type
Grouped, as opposed to a single Generic AVP that can contain an arbitrary set
of AVPs.

I think the new approach is a much cleaner approach.

PatC




From owner-aaa-bof@merit.edu  Fri Jan 19 17:53:38 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07576
	for <aaa-archive@odin.ietf.org>; Fri, 19 Jan 2001 17:53:38 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 147B05DE75; Fri, 19 Jan 2001 17:53:22 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 02E765DDD1; Fri, 19 Jan 2001 17:53:21 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id B7EBF5DDB2
	for <aaa-wg@merit.edu>; Fri, 19 Jan 2001 17:53:20 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10437;
	Fri, 19 Jan 2001 14:53:18 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA00855;
	Fri, 19 Jan 2001 14:53:16 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA24870;
	Fri, 19 Jan 2001 14:53:15 -0800 (PST)
Date: Fri, 19 Jan 2001 14:49:31 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Cc: "'Pat.Calhoun@Eng.Sun.COM'" <Pat.Calhoun@eng.sun.com>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FE57@eestqnt104.es.eu.ericsson.se>
Message-ID: <Roam.SIMC.2.0.6.979944571.10411.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Pat,
> 
> Comments making no sense to you are most probably related to my ignorance...
> However, I'd appreciate you help me out on this.

and responses making no sense to you are most probably related to my
ignorance...

:)

> 
> 
> Section 3.0 - par.2
> -------------------
> It is weird to me that we refer to an Authorization-Lifetime AVP in the Base
> Protocol without having any authorization message in it. Now we have the
> Session-Timeout AVP and the Authorization-Lifetime AVP which are somehow
> competing together.

No, they aren't intended to compete. Dave Mitton was the one that had come up
with the Authorization-Lifetime AVP in the solutions I-D. The
Authentication-Lifetime specifies how long before a re-auth should occur. The
Session-Time, on the other hand, states how long the session can occur. After
Session-Time, a session MUST be torn down. 

> Should the Authorization-Lifetime AVP be included in a
> specific extension, such as NASREQ, or is it because it might be used by
> several extensions without any specific meaning to the base protocol itself,
> which happens to be pretty much the same as the Session-Timeout AVP? My
> understanding is that there is not much to do with the
> Authorization-Lifetime AVP in the base protocol, since the action to take
> upon its expiration is defined in the NASREQ extension anyway, which is very
> specific. 
The reason why it is in the base protocol is to reduce duplicate AVPs in
extensions. I environ that all access methods will require some session
lifetime, so since it is used in many extensions, it seems appropriate to put
it in the base protocol.

> I guess that something more generic would be a Session-Timeout AVP
> which could trigger an STI when it expires that could lead to another
> re-authentication or something else in order to avoid the session to
> terminate right away. Then the NASREQ extension!
>  could possibly override that meaning by defining its own
> Authorization-Lifetime AVP which would trigger a more efficient an
> AA-Challenge-Ind instead.

Please read the above intended definitions of both AVPs and tell me if
additional changes are still required. Perhaps the actual definition of both
AVPs need some work. Is this sufficient?

> 
> Section 3.2 and 3.3
> -------------------
> Can the server return a bigger value?

bigger than what?

> What the value 0 means? The same as if it was not there?
> Which one has priority?
0 and not present are the same. They mean infinity (and I fixed the text in
Authorization-Lifetime)

> 
> Section 3.5
> -----------
> "Since the Session-Id is typically tied to a particular service (i.e. Mobile
> IP, NASREQ, etc), the session termination messages are used to request that
> the service tied to the Session Id be terminated."
> 
> It seems to be against last paragraph of section 3.1, which is "Note that a
> Session-Id MAY be used by more than one extension (e.g. authentication for a
> specific service and accounting, both of which have separate extensions).

hmmmm.... I believe that section 3.5 should state that the Extension-Id is
used to identify which service should be terminated. Does this make more sense?
 > 
> Section 3.5.2
> -------------
> What the Resource-Owner-NAI AVP used for in the STR? Is it for routing? I
> guess not, since the User-Name AVP is present. Can it be used in the server
> for any particular reason I don't see, since I think the active session
> should be aware of what's going on within itself, right?

If the home server wishes for the NAS to reliquish resources, then the
User-name AVP doesn't really help since it would cause the packet to get
routed to the home server (loop). So something is needed for the message to
get routed to the NAS, and I envisioned was that the AVP would be used for
routing purposes (and eventually get to the NAS).

> 
> Section 3.5.3
> -------------
> What is the purpose of the STA, since the session in the server and in the
> proxies should be released after the STR? What can the NAS or the server do
> if the STR is rejected and the resources are already released in the
> DIAMETER client and the proxies?

The STA acks the STR. The sender of the STR should wait until the STA is
received before releases resources.

> 
> Section 3.5.4
> -------------
> AVP Code 293
oops

Thanks!

PatC





From owner-aaa-bof@merit.edu  Fri Jan 19 18:21:46 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07831
	for <aaa-archive@odin.ietf.org>; Fri, 19 Jan 2001 18:21:46 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 7F6EF5DDB2; Fri, 19 Jan 2001 18:20:09 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 685695DDD1; Fri, 19 Jan 2001 18:20:09 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 48A7C5DDB2
	for <aaa-wg@merit.edu>; Fri, 19 Jan 2001 18:20:08 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA26165;
	Fri, 19 Jan 2001 15:20:05 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA07213;
	Fri, 19 Jan 2001 15:20:04 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA25319;
	Fri, 19 Jan 2001 15:20:02 -0800 (PST)
Date: Fri, 19 Jan 2001 15:16:18 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: [AAA-WG]: Re: DIAMETER Base Protocol (18-Alpha 1) draft / MRI 
To: Bob Kopacz <BKopacz@InterlinkNetworks.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>, Aaa-Wg <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <NEBBKEONLKEDJCMHGHPIIEHLCAAA.BKopacz@InterlinkNetworks.com>
Message-ID: <Roam.SIMC.2.0.6.979946178.1270.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Hi Pat,
> 
> Here are some questions on the DIAMETER Base Protocol (18-Alpha 1)
> draft.  The gist of what follows is:
> 
> (a) the draft's phrase "Extension Response + Result-Code" is ambiguous, and
> 
> (b) There may be error conditions where an MRI can't be sent, yet no
> appropriate extension response is available.

ok.

> 
> 
> 
> 5.0  Error Reporting
> --------------------
> 
> The draft says:
> 
>    "Extension Response + Result-Code" indicates that the appropriate
>    Response to the message MUST be sent with the Result-Code AVP set to
>    a value that enables the peer to understand the nature of the
>    problem.
> 
> Problem 1: The phrase "Extension Response + Result-Code" is
> ambiguous.  Does "Extension Response + Result-Code" mean "a response
> with an extension-specific command code", or "a response specified
> by the extension, but which may be an MRI"?  If the first meaning,
> perhaps the draft-18's text could be clarified by adding the
> following sentence to the paragraph:
> 
>    The Response has an extension-specific command code.

great suggestion.
> 
> - - -
> 
> Draft-18 specifies a more limited role for the MRI message.  That
> is, between draft-17 and draft-18, some of the 'X's in the following
> table from section 5.0 have shifted from the "Send
> Message-Reject-Ind" column into the "Extension Response +
> Result-Code" column.
> 
> Draft-17 said:
> 
> >    Error Type        Ignore Message          Send         Extension
> >                                       Message-Reject-Ind  Response +
> >                                                           Result-Code
> >    Bad Message              X
> >    Unknown Command                            X
> >    Unknown AVP                                X
> >    Bad Value                                  X
> >    Extension Error                                            X
> 
> Draft-18-Alpha 1 says:
> 
> >    Error Type        Ignore Message          Send         Extension
> >                                       Message-Reject-Ind  Response +
> >                                                           Result-Code
> >    Bad Message              X
> >    Unknown Command                            X
> >    Unknown AVP                                                X
> >    Bad AVP Value                                              X
> >    Extension Error                                            X
> 
> This shift to an extension-specific response is probably because a
> proxy which routes on Diameter extension wouldn't know how to route
> an MRI.

correct.

> 
> Problem 2: Assuming that "Extension Response + Result-Code" means "a
> response with an extension-specific command code", it seems like the
> MRI is limited to dealing with (a) DRI errors and (b) Unknown
> Command errors.  But some recent mailing list questions suggest that
> there may be error conditions other than (a) or (b), where no
> appropriate extension response is available.  

Actually, I believe the MRI is used for:
- Negative ack of any DRI, *-Answer or *-Response message, and
- Unknown command code

> 
> [One of the emails I am referring to is the "DIAMETER Base Protocol
> (18-Alpha 1)" draft / 5.0 Error Reporting" email of 16-Jan-2001,
> suggesting that a receiver of a reply packet which contains a bad
> AVP may want to send an MRI.  Another is the "Re: Comments on
> draft-calhoun-diameter-18.txt" email of 17-Jan-2001, suggesting that
> an MRI is a candidate to recover from a looped proxy chain.]

hmmmm... no I believe the above conditions are the only ones that require MRI
support.

PatC




From owner-aaa-bof@merit.edu  Fri Jan 19 19:22:20 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08373
	for <aaa-archive@odin.ietf.org>; Fri, 19 Jan 2001 19:22:19 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 72F6C5DEAA; Fri, 19 Jan 2001 19:21:41 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 62B0A5DEA8; Fri, 19 Jan 2001 19:21:41 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id E7D8F5DE06
	for <aaa-wg@merit.edu>; Fri, 19 Jan 2001 19:21:39 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA17127;
	Fri, 19 Jan 2001 16:21:38 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA22701;
	Fri, 19 Jan 2001 16:21:36 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA26764;
	Fri, 19 Jan 2001 16:21:35 -0800 (PST)
Date: Fri, 19 Jan 2001 16:17:51 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: [AAA-WG]: Alpha 2 of base protocol available
To: aaa-wg@merit.edu, diameter@diameter.org
Message-ID: <Roam.SIMC.2.0.6.979949871.7960.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

All,

Given the number of comments I've received in the past week, I decided to make
an Alpha 2 version available for review. The document, and associated diff
file, are available at the diameter web site (www.diameter.org).

There are still some pending questions in a few threads, so I expect a third
alpha before I send it off to the secretariat.

Thanks to all those that provided the great feedback!

PatC




From owner-aaa-bof@merit.edu  Fri Jan 19 19:25:35 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08403
	for <aaa-archive@odin.ietf.org>; Fri, 19 Jan 2001 19:25:35 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id D358F5DEB6; Fri, 19 Jan 2001 19:25:19 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id C3FD35DEA8; Fri, 19 Jan 2001 19:25:19 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 8CF9A5DE06
	for <aaa-wg@merit.edu>; Fri, 19 Jan 2001 19:25:18 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06617;
	Fri, 19 Jan 2001 16:25:14 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA23297;
	Fri, 19 Jan 2001 16:25:13 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA01979;
	Fri, 19 Jan 2001 16:25:12 -0800 (PST)
Date: Fri, 19 Jan 2001 16:21:27 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: [AAA-WG]: Re: Comments on draft-calhoun-diameter-18.txt
To: Fredrik Johansson <fredrik.johansson@ipunplugged.com>
Cc: AAA Listan <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <MJEMJBGGCLLDLFFAHLJKAECMCFAA.fredrik.johansson@ipunplugged.com>
Message-ID: <Roam.SIMC.2.0.6.979950087.30340.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Hi
> 
> Found a type in section 8.2. The Command Codes that are specified within
> this specification should be 257, 259, 274-276
> Compare section 8.2 with 2.1

check. 

Thanks,

PatC




From owner-aaa-bof@merit.edu  Mon Jan 22 10:27:00 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06419
	for <aaa-archive@odin.ietf.org>; Mon, 22 Jan 2001 10:27:00 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 9165C5DDAA; Mon, 22 Jan 2001 10:26:31 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 7300D5DDAB; Mon, 22 Jan 2001 10:26:31 -0500 (EST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by segue.merit.edu (Postfix) with ESMTP id B96D05DDAA
	for <aaa-wg@merit.edu>; Mon, 22 Jan 2001 10:26:29 -0500 (EST)
Received: from esealnt406.al.sw.ericsson.se (esealnt406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f0MFQSd20024
	for <aaa-wg@merit.edu>; Mon, 22 Jan 2001 16:26:28 +0100 (MET)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Jan 22 16:27:17 2001 +0100
Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58)
	id <Z2G9HRY1>; Mon, 22 Jan 2001 16:26:27 +0100
Message-ID: <577066326047D41180AC00508B955DDA01D7FE64@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0
Date: Mon, 22 Jan 2001 16:25:09 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Pat,

Thanks for your answers. See my comments.

/Martin

> -----Original Message-----
> From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com]
> Sent: Friday, January 19, 2001 11:50 PM
> To: Martin Julien (ECE)
> Cc: 'Pat.Calhoun@Eng.Sun.COM'; 'aaa-wg@merit.edu'
> Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments
> Section 3.0
> > 
> > Section 3.0 - par.2
> > -------------------
> > It is weird to me that we refer to an 
> Authorization-Lifetime AVP in the Base
> > Protocol without having any authorization message in it. 
> Now we have the
> > Session-Timeout AVP and the Authorization-Lifetime AVP 
> which are somehow
> > competing together.
> 
> No, they aren't intended to compete. Dave Mitton was the one 
> that had come up
> with the Authorization-Lifetime AVP in the solutions I-D. The
> Authentication-Lifetime specifies how long before a re-auth 
> should occur. The
> Session-Time, on the other hand, states how long the session 
> can occur. After
> Session-Time, a session MUST be torn down. 
>
> > Should the Authorization-Lifetime AVP be included in a
> > specific extension, such as NASREQ, or is it because it 
> might be used by
> > several extensions without any specific meaning to the base 
> protocol itself,
> > which happens to be pretty much the same as the 
> Session-Timeout AVP? My
> > understanding is that there is not much to do with the
> > Authorization-Lifetime AVP in the base protocol, since the 
> action to take
> > upon its expiration is defined in the NASREQ extension 
> anyway, which is very
> > specific. 
> The reason why it is in the base protocol is to reduce 
> duplicate AVPs in
> extensions. I environ that all access methods will require 
> some session
> lifetime, so since it is used in many extensions, it seems 
> appropriate to put
> it in the base protocol.
>
> > I guess that something more generic would be a Session-Timeout AVP
> > which could trigger an STI when it expires that could lead 
> to another
> > re-authentication or something else in order to avoid the session to
> > terminate right away. Then the NASREQ extension!
> >  could possibly override that meaning by defining its own
> > Authorization-Lifetime AVP which would trigger a more efficient an
> > AA-Challenge-Ind instead.
> 
> Please read the above intended definitions of both AVPs and tell me if
> additional changes are still required. Perhaps the actual 
> definition of both
> AVPs need some work. Is this sufficient?

I think I understand the roles of the Authorization-Lifetime AVP and the Session-Timeout AVP. However, the Session-Timeout AVP is also used by the Mobile-IP extension protocol for the registration keys time-out, which seems to be quite similar to what is required by NAS for re-authentication/re-authorization. Should the Mobile-IP extension also refer to the Authorization-Lifetime AVP instead of the Session-Timeout AVP?

Should the Session-Timeout also trigger a STI? Should we be expecting the Proxies to release resources automatically when the Session-Timeout AVP has been reached? Otherwise, what really happens when the Session-Timeout AVP expires and a session must be torn down in a AAAH and the proxies?


> > 
> > Section 3.2 and 3.3
> > -------------------
> > Can the server return a bigger value?
> 
> bigger than what?

I was simply wondering if it was allowed for the AAAH to return a bigger value then the one that was sent as a hint from the DIAMETER client?

> > What the value 0 means? The same as if it was not there?
> > Which one has priority?
> 0 and not present are the same. They mean infinity (and I 
> fixed the text in
> Authorization-Lifetime)
> 
> > 
> > Section 3.5
> > -----------
> > "Since the Session-Id is typically tied to a particular 
> service (i.e. Mobile
> > IP, NASREQ, etc), the session termination messages are used 
> to request that
> > the service tied to the Session Id be terminated."
> > 
> > It seems to be against last paragraph of section 3.1, which 
> is "Note that a
> > Session-Id MAY be used by more than one extension (e.g. 
> authentication for a
> > specific service and accounting, both of which have 
> separate extensions).
> 
> hmmmm.... I believe that section 3.5 should state that the 
> Extension-Id is
> used to identify which service should be terminated. Does 
> this make more sense?

I guess you meant a Session-ID and an Extension-ID? Yes, that would be OK.

> > Section 3.5.2
> > -------------
> > What the Resource-Owner-NAI AVP used for in the STR? Is it 
> for routing? I
> > guess not, since the User-Name AVP is present. Can it be 
> used in the server
> > for any particular reason I don't see, since I think the 
> active session
> > should be aware of what's going on within itself, right?
> 
> If the home server wishes for the NAS to reliquish resources, then the
> User-name AVP doesn't really help since it would cause the 
> packet to get
> routed to the home server (loop). So something is needed for 
> the message to
> get routed to the NAS, and I envisioned was that the AVP 
> would be used for
> routing purposes (and eventually get to the NAS).

Then, are you telling me that the message routing can be done using other AVPs than the Routing-Realm AVP and the User-Name AVP? Also, is it really needed in the STR, which is sent from the access device to the Home AAA?

> > 
> > Section 3.5.3
> > -------------
> > What is the purpose of the STA, since the session in the 
> server and in the
> > proxies should be released after the STR? What can the NAS 
> or the server do
> > if the STR is rejected and the resources are already released in the
> > DIAMETER client and the proxies?
> 
> The STA acks the STR. The sender of the STR should wait until 
> the STA is
> received before releases resources.

The paragraph 3.5.2 says:

"Upon receipt of the STR, the Home DIAMETER Server SHOULD release all resources for the session indicated by the Session-Id AVP. Any intermediate server in the Proxy-Chain MAY also release any resources, if necessary."

That's the reason why I asked about the STA. Now you're telling me that it should be the STA that should trigger the release of resources, right?



From owner-aaa-bof@merit.edu  Mon Jan 22 10:40:26 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06739
	for <aaa-archive@odin.ietf.org>; Mon, 22 Jan 2001 10:40:26 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id E3B2F5DDAB; Mon, 22 Jan 2001 10:40:08 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id C72745DDBC; Mon, 22 Jan 2001 10:40:08 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id B1D005DDAB
	for <aaa-wg@merit.edu>; Mon, 22 Jan 2001 10:40:07 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25128;
	Mon, 22 Jan 2001 07:40:03 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA07626;
	Mon, 22 Jan 2001 07:40:00 -0800 (PST)
Received: from cinnamon (cinnamon [129.146.122.100])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA12680;
	Mon, 22 Jan 2001 07:39:53 -0800 (PST)
Date: Mon, 22 Jan 2001 07:38:43 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Cc: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FE64@eestqnt104.es.eu.ericsson.se>
Message-ID: <Roam.SIMC.2.0.6.980177923.27616.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Pat,
> 
> Thanks for your answers. See my comments.
> 
> /Martin
> 
> > -----Original Message-----
> > From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com]
> > Sent: Friday, January 19, 2001 11:50 PM
> > To: Martin Julien (ECE)
> > Cc: 'Pat.Calhoun@Eng.Sun.COM'; 'aaa-wg@merit.edu'
> > Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments
> > Section 3.0
> > > 
> > > Section 3.0 - par.2
> > > -------------------
> > > It is weird to me that we refer to an 
> > Authorization-Lifetime AVP in the Base
> > > Protocol without having any authorization message in it. 
> > Now we have the
> > > Session-Timeout AVP and the Authorization-Lifetime AVP 
> > which are somehow
> > > competing together.
> > 
> > No, they aren't intended to compete. Dave Mitton was the one 
> > that had come up
> > with the Authorization-Lifetime AVP in the solutions I-D. The
> > Authentication-Lifetime specifies how long before a re-auth 
> > should occur. The
> > Session-Time, on the other hand, states how long the session 
> > can occur. After
> > Session-Time, a session MUST be torn down. 
> >
> > > Should the Authorization-Lifetime AVP be included in a
> > > specific extension, such as NASREQ, or is it because it 
> > might be used by
> > > several extensions without any specific meaning to the base 
> > protocol itself,
> > > which happens to be pretty much the same as the 
> > Session-Timeout AVP? My
> > > understanding is that there is not much to do with the
> > > Authorization-Lifetime AVP in the base protocol, since the 
> > action to take
> > > upon its expiration is defined in the NASREQ extension 
> > anyway, which is very
> > > specific. 
> > The reason why it is in the base protocol is to reduce 
> > duplicate AVPs in
> > extensions. I environ that all access methods will require 
> > some session
> > lifetime, so since it is used in many extensions, it seems 
> > appropriate to put
> > it in the base protocol.
> >
> > > I guess that something more generic would be a Session-Timeout AVP
> > > which could trigger an STI when it expires that could lead 
> > to another
> > > re-authentication or something else in order to avoid the session to
> > > terminate right away. Then the NASREQ extension!
> > >  could possibly override that meaning by defining its own
> > > Authorization-Lifetime AVP which would trigger a more efficient an
> > > AA-Challenge-Ind instead.
> > 
> > Please read the above intended definitions of both AVPs and tell me if
> > additional changes are still required. Perhaps the actual 
> > definition of both
> > AVPs need some work. Is this sufficient?
> 
> I think I understand the roles of the Authorization-Lifetime AVP and the
> Session-Timeout AVP. However, the Session-Timeout AVP is also used by the
> Mobile-IP extension protocol for the registration keys time-out, which seems
> to be quite similar to what is required by NAS for
> re-authentication/re-authorization. Should the Mobile-IP extension also
> refer to the Authorization-Lifetime AVP instead of the Session-Timeout AVP?

Correct, and perhaps re-using the Session-Timeout was overloading the AVP.
Either Authorization-Lifetime should be used for the keys, or some new AVP
that is more specific to the keys.

> 
> Should the Session-Timeout also trigger a STI? Should we be expecting the
> Proxies to release resources automatically when the Session-Timeout AVP has
> been reached? Otherwise, what really happens when the Session-Timeout AVP
> expires and a session must be torn down in a AAAH and the proxies?

ok, so in the RADIUS world, it is implicit. No additional signaling is
required. Once the session times out, all nodes simply free resources. Of
course, there is no STI in RADIUS. So, what should we do? Maintain the RADIUS
model, or explicit signaling?

Comments?

> > > Section 3.2 and 3.3
> > > -------------------
> > > Can the server return a bigger value?
> > 
> > bigger than what?
> 
> I was simply wondering if it was allowed for the AAAH to return a bigger
> value then the one that was sent as a hint from the DIAMETER client?

Ah, good question. Again, in the RADIUS world, the RADIUS server can return
pretty much what it wants. A hint from a client does not imply a maximum, so I
believe that the server should be able to return anything it wants.

Other comments on this one? Anyone disagree?

> > > 
> > > Section 3.5
> > > -----------
> > > "Since the Session-Id is typically tied to a particular 
> > service (i.e. Mobile
> > > IP, NASREQ, etc), the session termination messages are used 
> > to request that
> > > the service tied to the Session Id be terminated."
> > > 
> > > It seems to be against last paragraph of section 3.1, which 
> > is "Note that a
> > > Session-Id MAY be used by more than one extension (e.g. 
> > authentication for a
> > > specific service and accounting, both of which have 
> > separate extensions).
> > 
> > hmmmm.... I believe that section 3.5 should state that the 
> > Extension-Id is
> > used to identify which service should be terminated. Does 
> > this make more sense?
> 
> I guess you meant a Session-ID and an Extension-ID? Yes, that would be OK.
correct.

> 
> > > Section 3.5.2
> > > -------------
> > > What the Resource-Owner-NAI AVP used for in the STR? Is it 
> > for routing? I
> > > guess not, since the User-Name AVP is present. Can it be 
> > used in the server
> > > for any particular reason I don't see, since I think the 
> > active session
> > > should be aware of what's going on within itself, right?
> > 
> > If the home server wishes for the NAS to reliquish resources, then the
> > User-name AVP doesn't really help since it would cause the 
> > packet to get
> > routed to the home server (loop). So something is needed for 
> > the message to
> > get routed to the NAS, and I envisioned was that the AVP 
> > would be used for
> > routing purposes (and eventually get to the NAS).
> 
> Then, are you telling me that the message routing can be done using other
> AVPs than the Routing-Realm AVP and the User-Name AVP? Also, is it really
> needed in the STR, which is sent from the access device to the Home AAA?

In the STR no, only in the STI. Can anyone think of a better mechanism? I
really don't know of a better way to do this.


> 
> > > 
> > > Section 3.5.3
> > > -------------
> > > What is the purpose of the STA, since the session in the 
> > server and in the
> > > proxies should be released after the STR? What can the NAS 
> > or the server do
> > > if the STR is rejected and the resources are already released in the
> > > DIAMETER client and the proxies?
> > 
> > The STA acks the STR. The sender of the STR should wait until 
> > the STA is
> > received before releases resources.
> 
> The paragraph 3.5.2 says:
> 
> "Upon receipt of the STR, the Home DIAMETER Server SHOULD release all
> resources for the session indicated by the Session-Id AVP. Any intermediate
> server in the Proxy-Chain MAY also release any resources, if necessary."
> 
> That's the reason why I asked about the STA. Now you're telling me that it
> should be the STA that should trigger the release of resources, right?

I will clean up the text. The sender of the STR cleans up after receiving the
STA, while the receiver of the STR cleans up while receiving the STR.

PatC




From owner-aaa-bof@merit.edu  Mon Jan 22 10:49:00 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06917
	for <aaa-archive@odin.ietf.org>; Mon, 22 Jan 2001 10:48:59 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 7130C5DE01; Mon, 22 Jan 2001 10:45:48 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 488F55DF60; Mon, 22 Jan 2001 10:45:48 -0500 (EST)
Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44])
	by segue.merit.edu (Postfix) with ESMTP id 343A85DE01
	for <aaa-wg@merit.edu>; Mon, 22 Jan 2001 10:45:46 -0500 (EST)
Received: (from barney@localhost)
	by mx.databus.com (8.11.1/8.11.1) id f0MFjPK14695;
	Mon, 22 Jan 2001 10:45:25 -0500 (EST)
	(envelope-from barney)
Date: Mon, 22 Jan 2001 10:45:25 -0500
From: Barney Wolff <barney@databus.com>
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Cc: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0
Message-ID: <20010122104524.A14651@mx.databus.com>
References: <577066326047D41180AC00508B955DDA01D7FE64@eestqnt104.es.eu.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <577066326047D41180AC00508B955DDA01D7FE64@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Mon, Jan 22, 2001 at 04:25:09PM +0100
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Why does DIAMETER need to specify such within-node behavior?
Is any of it visible outside the node?

Barney Wolff

On Mon, Jan 22, 2001 at 04:25:09PM +0100, Martin Julien (ECE) wrote:
> > > 
> > > Section 3.5.3
> > > -------------
> > > What is the purpose of the STA, since the session in the 
> > server and in the
> > > proxies should be released after the STR? What can the NAS 
> > or the server do
> > > if the STR is rejected and the resources are already released in the
> > > DIAMETER client and the proxies?
> > 
> > The STA acks the STR. The sender of the STR should wait until 
> > the STA is
> > received before releases resources.
> 
> The paragraph 3.5.2 says:
> 
> "Upon receipt of the STR, the Home DIAMETER Server SHOULD release all resources for the session indicated by the Session-Id AVP. Any intermediate server in the Proxy-Chain MAY also release any resources, if necessary."
> 
> That's the reason why I asked about the STA. Now you're telling me that it should be the STA that should trigger the release of resources, right?
> 



From owner-aaa-bof@merit.edu  Mon Jan 22 11:19:11 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07782
	for <aaa-archive@odin.ietf.org>; Mon, 22 Jan 2001 11:19:10 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 8BFD75DE3B; Mon, 22 Jan 2001 11:16:28 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 78D5B5DDC3; Mon, 22 Jan 2001 11:16:28 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 2F1875DE3B
	for <aaa-wg@merit.edu>; Mon, 22 Jan 2001 11:16:27 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24573;
	Mon, 22 Jan 2001 08:16:22 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA21433;
	Mon, 22 Jan 2001 08:16:21 -0800 (PST)
Received: from cinnamon (cinnamon [129.146.122.100])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA13108;
	Mon, 22 Jan 2001 08:16:19 -0800 (PST)
Date: Mon, 22 Jan 2001 08:15:26 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0
To: Barney Wolff <barney@databus.com>
Cc: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <20010122104524.A14651@mx.databus.com>
Message-ID: <Roam.SIMC.2.0.6.980180126.11902.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Why does DIAMETER need to specify such within-node behavior?
> Is any of it visible outside the node?

If state is released implicitly, then a sentence explaining the purpose of the
Session-Timeout AVP is sufficient. However, if explicit signaling is used to
release resources, then it is visible outside the node.

PatC




From owner-aaa-bof@merit.edu  Mon Jan 22 11:28:37 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07991
	for <aaa-archive@odin.ietf.org>; Mon, 22 Jan 2001 11:28:36 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 475065DDC3; Mon, 22 Jan 2001 11:28:19 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 2EFC75DDD9; Mon, 22 Jan 2001 11:28:19 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by segue.merit.edu (Postfix) with ESMTP id 2DD985DDC3
	for <aaa-wg@merit.edu>; Mon, 22 Jan 2001 11:28:13 -0500 (EST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f0MGSBC16816
	for <aaa-wg@merit.edu>; Mon, 22 Jan 2001 17:28:12 +0100 (MET)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Mon Jan 22 17:28:16 2001 +0100
Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58)
	id <Z2G9H49H>; Mon, 22 Jan 2001 17:28:11 +0100
Message-ID: <577066326047D41180AC00508B955DDA01D7FE66@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments
Date: Mon, 22 Jan 2001 17:26:52 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Pat,

Please, see some minor comments inline.

Thanks,
Martin

> From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com]
> Sent: Friday, January 19, 2001 11:29 PM
> > 
> > 
> > Section 2.0 - par.5
> > -------------------
> > "Session state (associated with a Session-Id) MUST be freed 
> upon receipt of
> > the Session-Termination-Request, 
> Session-Termination-Answer, expiration of
> > authorized service time in the Session-Timeout AVP, and 
> according to rules
> > established in a particular extension/application of DIAMETER."
> > 
> > I think this sentence is confusing me. Are you trying to 
> show the real
> > trigger for the session release, the STR (as in section 
> 3.5.2), or the
> > reasons why an STR could have been sent? It seems to me that the
> > "Session-Termination-Answer, expiration of authorized 
> service time in the
> > Session-Timeout AVP, and according to rules established in 
> a particular
> > extension/application of DIAMETER." part is more related to 
> original reasons
> > why an STR has been sent. Also, it is confusing to read 
> "authorized service
> > time in the Session-Timeout AVP" when you can also refer to 
> the reason that
> > the "authorization-lifetime-AVP" might have time-out as 
> well, which I assume
> > would trigger an STR. I need more info from you if you want 
> me to propose
> > something else.
> 
> I think that the confusion is largely in the quoted text. 
> What the above
> attempts to state is that servers that maintain state needs 
> to relinquish such
> state when: 1. A Session-Termination-Request is received,
> 2. A Session-Termination-Answer is received,
> 3. The session has timed out (which does NOT require sending 
> any termination 
>    messages), or
> 4. Any other rules specified in extensions.
> 
> Does this help? If so, I can itemize each condition in the 
> draft. I think this
> would read better anyway.

Yes, but it would help if you could also clarify the fact that resources in proxies and DIAMETER clients should be released only when a STA is received, and released in the Home AAA when a STA is about to be sent (or STR received).


> > 
> > Section 2.5 - par.1
> > -------------------
> > "...the Device-Reboot-Ind message MUST contain one 
> Host-IP-Address AVP for
> > each potential IP address that MAY be locally used when transmitting
> > DIAMETER messages."
> > 
> > Please, could you tell me briefly why we need to send all 
> IP addresses of
> > the device? I guess it is because the device is not 
> registered into a DNS
> > and we want to build an internal DNS inside the DIAMETER 
> server along with
> > the Host-Name AVP for message routing, right? Should we 
> have a dynamic or
> > static DNS in the server?
> 
> It was intended to fully support SCTP, which inherently 
> supports multi-homed
> servers.

Which means that it is suggested for a DIAMETER server to maintain a dynamic "DNS" containing all the IP addresses of the clients for SCTP to support multi-homing? This is then an AVP which is transport dependent, right? Should it really be an AVP Mandatory (M), as it is right now? 


> > Section 5.2.4
> > -------------
> > "...but MAY be able to satisfy the request in the future."
> > What does this mean exactly? Does it mean that a server 
> should be able to
> > resend the request in a few minutes without any specific 
> changes to the
> > message besides the timestamp for example? Should it be regarded as
> > temporary congestion? 
> 
> It is intended to contain errors that occur due to some 
> temporary condition,
> and the request can be tried again later. I am not sure how to express
> "future". A timestamp may not really help, since the server 
> may not know when
> the administrator will free up some disk space (as an example).
> 
> > If it is the case, then maybe we should think of
> > moving the DIAMETER_AUTHENTICATION_REJECTED and 
> DIAMETER_CONTRACTING_AVPS to
> > the permanent failure section. I think that permanent 
> result codes should be
> > used in the rejected message even if the originating server 
> can change AVPs
> > in the message which has been rejected the first time for 
> some reasons such
> > as unsupported mandatory AVPs, because it is no longer the 
> same message
> > anyway, and the first message was really considered as a 
> permanent failure
> > in this particular period of time. 
> yes, you are right. I will move these.

It seems that you have missed the DIAMETER_AUTHENTICATION_REJECTED one.



From owner-aaa-bof@merit.edu  Mon Jan 22 11:50:10 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08477
	for <aaa-archive@odin.ietf.org>; Mon, 22 Jan 2001 11:50:10 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id DC3235DF4C; Mon, 22 Jan 2001 11:47:45 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id CADB65DF4A; Mon, 22 Jan 2001 11:47:45 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by segue.merit.edu (Postfix) with ESMTP id 03D435DF48
	for <aaa-wg@merit.edu>; Mon, 22 Jan 2001 11:47:43 -0500 (EST)
Received: from esealnt462.al.sw.ericsson.se (esealnt462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f0MGlhC27134
	for <aaa-wg@merit.edu>; Mon, 22 Jan 2001 17:47:43 +0100 (MET)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Jan 22 17:48:32 2001 +0100
Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58)
	id <Z2G9HVZQ>; Mon, 22 Jan 2001 17:47:42 +0100
Message-ID: <577066326047D41180AC00508B955DDA01D7FE67@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0
Date: Mon, 22 Jan 2001 17:46:24 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Pat,

See comments inline.

Martin

> From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com]
> Sent: Monday, January 22, 2001 4:39 PM
>
> > > > Section 3.5.2
> > > > -------------
> > > > What the Resource-Owner-NAI AVP used for in the STR? Is it 
> > > for routing? I
> > > > guess not, since the User-Name AVP is present. Can it be 
> > > used in the server
> > > > for any particular reason I don't see, since I think the 
> > > active session
> > > > should be aware of what's going on within itself, right?
> > > 
> > > If the home server wishes for the NAS to reliquish 
> resources, then the
> > > User-name AVP doesn't really help since it would cause the 
> > > packet to get
> > > routed to the home server (loop). So something is needed for 
> > > the message to
> > > get routed to the NAS, and I envisioned was that the AVP 
> > > would be used for
> > > routing purposes (and eventually get to the NAS).
> > 
> > Then, are you telling me that the message routing can be 
> done using other
> > AVPs than the Routing-Realm AVP and the User-Name AVP? 
> Also, is it really
> > needed in the STR, which is sent from the access device to 
> the Home AAA?
> 
> In the STR no, only in the STI. Can anyone think of a better 
> mechanism? I
> really don't know of a better way to do this.

Shouldn't we use the Routing-Realm AVP in order to reach the access device? Then, would you obsolete the Resource-Owner-NAI AVP, or do you see any further need for it? 

My understanding was that the Routing-Realm AVP was the destination of the message, as it is routed through the network, and the Host-Name AVP the originator of the message, which should never change during the message transit to its final destination. However, what could cause problems is the fact that some proxies might modify the Routing-Realm AVP in transit, right?



From owner-aaa-bof@merit.edu  Mon Jan 22 11:52:03 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08538
	for <aaa-archive@odin.ietf.org>; Mon, 22 Jan 2001 11:52:03 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id C42175DF41; Mon, 22 Jan 2001 11:49:09 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id AA3835DF1A; Mon, 22 Jan 2001 11:49:09 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 485FB5DF41
	for <aaa-wg@merit.edu>; Mon, 22 Jan 2001 11:49:08 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29367;
	Mon, 22 Jan 2001 08:49:05 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA27706;
	Mon, 22 Jan 2001 08:49:05 -0800 (PST)
Received: from cinnamon (cinnamon [129.146.122.100])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA13553;
	Mon, 22 Jan 2001 08:49:03 -0800 (PST)
Date: Mon, 22 Jan 2001 08:48:10 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Cc: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FE66@eestqnt104.es.eu.ericsson.se>
Message-ID: <Roam.SIMC.2.0.6.980182090.7036.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Pat,
> 
> Please, see some minor comments inline.

as are mine...

PatC

> > > Section 2.0 - par.5
> > > -------------------
> > > "Session state (associated with a Session-Id) MUST be freed 
> > upon receipt of
> > > the Session-Termination-Request, 
> > Session-Termination-Answer, expiration of
> > > authorized service time in the Session-Timeout AVP, and 
> > according to rules
> > > established in a particular extension/application of DIAMETER."
> > > 
> > > I think this sentence is confusing me. Are you trying to 
> > show the real
> > > trigger for the session release, the STR (as in section 
> > 3.5.2), or the
> > > reasons why an STR could have been sent? It seems to me that the
> > > "Session-Termination-Answer, expiration of authorized 
> > service time in the
> > > Session-Timeout AVP, and according to rules established in 
> > a particular
> > > extension/application of DIAMETER." part is more related to 
> > original reasons
> > > why an STR has been sent. Also, it is confusing to read 
> > "authorized service
> > > time in the Session-Timeout AVP" when you can also refer to 
> > the reason that
> > > the "authorization-lifetime-AVP" might have time-out as 
> > well, which I assume
> > > would trigger an STR. I need more info from you if you want 
> > me to propose
> > > something else.
> > 
> > I think that the confusion is largely in the quoted text. 
> > What the above
> > attempts to state is that servers that maintain state needs 
> > to relinquish such
> > state when: 1. A Session-Termination-Request is received,
> > 2. A Session-Termination-Answer is received,
> > 3. The session has timed out (which does NOT require sending 
> > any termination 
> >    messages), or
> > 4. Any other rules specified in extensions.
> > 
> > Does this help? If so, I can itemize each condition in the 
> > draft. I think this
> > would read better anyway.
> 
> Yes, but it would help if you could also clarify the fact that resources in
> proxies and DIAMETER clients should be released only when a STA is received,
> and released in the Home AAA when a STA is about to be sent (or STR
> received).

ok.
> 
> 
> > > 
> > > Section 2.5 - par.1
> > > -------------------
> > > "...the Device-Reboot-Ind message MUST contain one 
> > Host-IP-Address AVP for
> > > each potential IP address that MAY be locally used when transmitting
> > > DIAMETER messages."
> > > 
> > > Please, could you tell me briefly why we need to send all 
> > IP addresses of
> > > the device? I guess it is because the device is not 
> > registered into a DNS
> > > and we want to build an internal DNS inside the DIAMETER 
> > server along with
> > > the Host-Name AVP for message routing, right? Should we 
> > have a dynamic or
> > > static DNS in the server?
> > 
> > It was intended to fully support SCTP, which inherently 
> > supports multi-homed
> > servers.
> 
> Which means that it is suggested for a DIAMETER server to maintain a dynamic
> "DNS" containing all the IP addresses of the clients for SCTP to support
> multi-homing? This is then an AVP which is transport dependent, right?
> Should it really be an AVP Mandatory (M), as it is right now? 

AAA servers should not be DNS servers. This is really an implementation issue,
and the internals of the server shouldn't be discussed, IMHO. 

Yes, I think 'M' is correct.

> 
> 
> > > Section 5.2.4
> > > -------------
> > > "...but MAY be able to satisfy the request in the future."
> > > What does this mean exactly? Does it mean that a server 
> > should be able to
> > > resend the request in a few minutes without any specific 
> > changes to the
> > > message besides the timestamp for example? Should it be regarded as
> > > temporary congestion? 
> > 
> > It is intended to contain errors that occur due to some 
> > temporary condition,
> > and the request can be tried again later. I am not sure how to express
> > "future". A timestamp may not really help, since the server 
> > may not know when
> > the administrator will free up some disk space (as an example).
> > 
> > > If it is the case, then maybe we should think of
> > > moving the DIAMETER_AUTHENTICATION_REJECTED and 
> > DIAMETER_CONTRACTING_AVPS to
> > > the permanent failure section. I think that permanent 
> > result codes should be
> > > used in the rejected message even if the originating server 
> > can change AVPs
> > > in the message which has been rejected the first time for 
> > some reasons such
> > > as unsupported mandatory AVPs, because it is no longer the 
> > same message
> > > anyway, and the first message was really considered as a 
> > permanent failure
> > > in this particular period of time. 
> > yes, you are right. I will move these.
> 
> It seems that you have missed the DIAMETER_AUTHENTICATION_REJECTED one.

I will check.

Thanks,

PatC




From owner-aaa-bof@merit.edu  Mon Jan 22 12:12:17 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09130
	for <aaa-archive@odin.ietf.org>; Mon, 22 Jan 2001 12:12:17 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 64C175DDD9; Mon, 22 Jan 2001 12:11:57 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 4F4845DE34; Mon, 22 Jan 2001 12:11:57 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 3182F5DDD9
	for <aaa-wg@merit.edu>; Mon, 22 Jan 2001 12:11:56 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA22062;
	Mon, 22 Jan 2001 09:11:52 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA02452;
	Mon, 22 Jan 2001 09:11:47 -0800 (PST)
Received: from cinnamon (cinnamon [129.146.122.100])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA13899;
	Mon, 22 Jan 2001 09:11:39 -0800 (PST)
Date: Mon, 22 Jan 2001 09:10:46 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Cc: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FE67@eestqnt104.es.eu.ericsson.se>
Message-ID: <Roam.SIMC.2.0.6.980183446.23306.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Pat,
> 
> See comments inline.
> 
> Martin
> 
> > From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com]
> > Sent: Monday, January 22, 2001 4:39 PM
> >
> > > > > Section 3.5.2
> > > > > -------------
> > > > > What the Resource-Owner-NAI AVP used for in the STR? Is it 
> > > > for routing? I
> > > > > guess not, since the User-Name AVP is present. Can it be 
> > > > used in the server
> > > > > for any particular reason I don't see, since I think the 
> > > > active session
> > > > > should be aware of what's going on within itself, right?
> > > > 
> > > > If the home server wishes for the NAS to reliquish 
> > resources, then the
> > > > User-name AVP doesn't really help since it would cause the 
> > > > packet to get
> > > > routed to the home server (loop). So something is needed for 
> > > > the message to
> > > > get routed to the NAS, and I envisioned was that the AVP 
> > > > would be used for
> > > > routing purposes (and eventually get to the NAS).
> > > 
> > > Then, are you telling me that the message routing can be 
> > done using other
> > > AVPs than the Routing-Realm AVP and the User-Name AVP? 
> > Also, is it really
> > > needed in the STR, which is sent from the access device to 
> > the Home AAA?
> > 
> > In the STR no, only in the STI. Can anyone think of a better 
> > mechanism? I
> > really don't know of a better way to do this.
> 
> Shouldn't we use the Routing-Realm AVP in order to reach the access device?
> Then, would you obsolete the Resource-Owner-NAI AVP, or do you see any
> further need for it? 
> 
> My understanding was that the Routing-Realm AVP was the destination of the
> message, as it is routed through the network, and the Host-Name AVP the
> originator of the message, which should never change during the message
> transit to its final destination. However, what could cause problems is the
> fact that some proxies might modify the Routing-Realm AVP in transit, right?

I didn't think that Routing-Realm would pin point a particular NAS, but rather
the domain that it happens to be in. Isn't this your understanding as well?

PatC




From owner-aaa-bof@merit.edu  Mon Jan 22 13:20:34 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10950
	for <aaa-archive@odin.ietf.org>; Mon, 22 Jan 2001 13:20:33 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id CA2C85DF35; Mon, 22 Jan 2001 13:19:09 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id B86725DF33; Mon, 22 Jan 2001 13:19:09 -0500 (EST)
Received: from ctron-dnm.ctron.com (ctron-dnm.cabletron.com [12.25.1.120])
	by segue.merit.edu (Postfix) with ESMTP id A06765DE45
	for <aaa-wg@merit.edu>; Mon, 22 Jan 2001 13:19:08 -0500 (EST)
Received: (from uucp@localhost)
	by ctron-dnm.ctron.com (8.8.7/8.8.7) id NAA00723;
	Mon, 22 Jan 2001 13:24:52 -0500 (EST)
Received: from cnc-exc1.ctron.com(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1)
	id xma000646; Mon, 22 Jan 01 13:23:46 -0500
Received: from cnc-exc1.ctron.com (localhost [127.0.0.1]) by cnc-exc1.ctron.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id D1KM8XQY; Mon, 22 Jan 2001 13:17:58 -0500
Received: from 10.8.9.185 by cnc-exc1.ctron.com (InterScan E-Mail VirusWall NT); Mon, 22 Jan 2001 13:17:57 -0500 (Eastern Standard Time)
Message-ID: <3A6C782B.EBC47599@enterasys.com>
Date: Mon, 22 Jan 2001 13:12:59 -0500
From: David Harrington <dbh@enterasys.com>
Reply-To: dbh@enterasys.com
Organization: Enterasys Networks
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Cc: Bob Kopacz <BKopacz@InterlinkNetworks.com>, Aaa-Wg <aaa-wg@merit.edu>
Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) / 2.5.1  Vendor-Name AVP
References: <Roam.SIMC.2.0.6.979251475.6508.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

I prefer the use of the enterprise ID. 
It is concise and factual. It should be satisfactual.
Applications can provide the translation to English for those that need
it.

dbh

Pat Calhoun wrote:
> 
> I have no idea why a name was chosen over the IANA managed value. I agree that
> using the value that one would find in the Vendor-Id field seems much more
> reasonable. I think that the name was added for debugging purpose so users
> (that have no idea what IANA, much less enterprise numbers) can figure out
> what's at the other end.
> 
> What do other prefer? Just the ID, or both?
> 
> Thanks for the great catch!
> 
> PatC
> > Hi Pat,
> >
> > The DRI contains a Vendor-Name AVP, which the draft says
> > is so that a Diameter peer might "know which vendor
> > specific attributes may be sent to the peer".
> >
> > Since it is the 32-bit vendor number that appears in the
> > AVP header and in the Diameter header, should the DRI
> > instead include a Vendor-ID AVP which contains the
> > vendor's enterprise code?  It seems a vendor ID value
> > would be more directly useful for the above-mentioned
> > purpose.
> >
> > Or if the Vendor-Name AVP is the way to go, should there
> > be a list of vendor name strings so that they can be
> > mapped to known vendors, and an indication if this string
> > is case-sensitive, etc.?
> >
> > The "DIAMETER Base Protocol (Alpha 1)" document says:
> >
> > > 2.5.1  Vendor-Name AVP
> > >
> > > The Vendor-Name AVP (AVP Code 266) is of type
> > > OctetString and is used to inform a DIAMETER peer of the
> > > Vendor Name of the DIAMETER device. This MAY be used in
> > > order to know which vendor specific attributes may be
> > > sent to the peer. It is also envisioned that the
> > > combination of the Vendor-Name and the Firmware-Revision
> > > (section 2.5.2) AVPs MAY provide very useful debugging
> > > information.
> >
> >

-- 
---
David Harrington            Network Management Standards Architect
dbh@enterasys.com           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA



From owner-aaa-bof@merit.edu  Mon Jan 22 13:30:11 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11199
	for <aaa-archive@odin.ietf.org>; Mon, 22 Jan 2001 13:30:11 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 0BF525DE14; Mon, 22 Jan 2001 13:29:49 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id E6D065DE1F; Mon, 22 Jan 2001 13:29:48 -0500 (EST)
Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44])
	by segue.merit.edu (Postfix) with ESMTP id 71DCB5DE14
	for <aaa-wg@merit.edu>; Mon, 22 Jan 2001 13:29:47 -0500 (EST)
Received: (from barney@localhost)
	by mx.databus.com (8.11.1/8.11.1) id f0MIThH15281;
	Mon, 22 Jan 2001 13:29:43 -0500 (EST)
	(envelope-from barney)
Date: Mon, 22 Jan 2001 13:29:43 -0500
From: Barney Wolff <barney@databus.com>
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: Barney Wolff <barney@databus.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0
Message-ID: <20010122132943.B15144@mx.databus.com>
References: <20010122104524.A14651@mx.databus.com> <Roam.SIMC.2.0.6.980180126.11902.pcalhoun@nasnfs>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Roam.SIMC.2.0.6.980180126.11902.pcalhoun@nasnfs>; from Pat.Calhoun@eng.sun.com on Mon, Jan 22, 2001 at 08:15:26AM -0800
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

I was commenting on language specifying when the server & proxy
must release resources (STR/STA).  I don't believe that has to
be specified.  All that needs to be said is that a server
must respond to STR with STA and a proxy must pass an STA back
to its client.  Specifying exactly when internal resources get
released is overkill, unless it has consequences on visible
behavior.  IMHO.

Barney

On Mon, Jan 22, 2001 at 08:15:26AM -0800, Pat Calhoun wrote:
> > Why does DIAMETER need to specify such within-node behavior?
> > Is any of it visible outside the node?
> 
> If state is released implicitly, then a sentence explaining the purpose of the
> Session-Timeout AVP is sufficient. However, if explicit signaling is used to
> release resources, then it is visible outside the node.
> 
> PatC
> 



From owner-aaa-bof@merit.edu  Mon Jan 22 13:34:50 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11293
	for <aaa-archive@odin.ietf.org>; Mon, 22 Jan 2001 13:34:50 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 23A2F5DEDF; Mon, 22 Jan 2001 13:33:13 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 1126F5DEA4; Mon, 22 Jan 2001 13:33:13 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id E786A5DE1F
	for <aaa-wg@merit.edu>; Mon, 22 Jan 2001 13:33:11 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA01056;
	Mon, 22 Jan 2001 10:32:32 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA23417;
	Mon, 22 Jan 2001 10:31:29 -0800 (PST)
Received: from cinnamon (cinnamon [129.146.122.100])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA15478;
	Mon, 22 Jan 2001 10:31:27 -0800 (PST)
Date: Mon, 22 Jan 2001 10:30:29 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0
To: Barney Wolff <barney@databus.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <20010122132943.B15144@mx.databus.com>
Message-ID: <Roam.SIMC.2.0.6.980188229.31656.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Ah, sorry for the misunderstanding. I do agree. Does anyone object?

PatC
> I was commenting on language specifying when the server & proxy
> must release resources (STR/STA).  I don't believe that has to
> be specified.  All that needs to be said is that a server
> must respond to STR with STA and a proxy must pass an STA back
> to its client.  Specifying exactly when internal resources get
> released is overkill, unless it has consequences on visible
> behavior.  IMHO.
> 
> Barney
> 
> On Mon, Jan 22, 2001 at 08:15:26AM -0800, Pat Calhoun wrote:
> > > Why does DIAMETER need to specify such within-node behavior?
> > > Is any of it visible outside the node?
> > 
> > If state is released implicitly, then a sentence explaining the purpose of the
> > Session-Timeout AVP is sufficient. However, if explicit signaling is used to
> > release resources, then it is visible outside the node.
> > 
> > PatC
> > 





From owner-aaa-bof@merit.edu  Tue Jan 23 02:34:26 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06607
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 02:34:25 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 4FF1B5DD94; Tue, 23 Jan 2001 02:31:29 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 2757F5DE0B; Tue, 23 Jan 2001 02:31:29 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by segue.merit.edu (Postfix) with ESMTP id 7600A5DD94
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 02:31:27 -0500 (EST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f0N7VQC02297
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 08:31:26 +0100 (MET)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Tue Jan 23 08:31:29 2001 +0100
Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58)
	id <Z2G9H693>; Tue, 23 Jan 2001 08:31:25 +0100
Message-ID: <577066326047D41180AC00508B955DDA01D7FE69@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0
Date: Tue, 23 Jan 2001 08:31:23 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

See enclosed comments.

> -----Original Message-----
> From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com]
> Sent: Monday, January 22, 2001 6:11 PM
> > 
> > > From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com]
> > > Sent: Monday, January 22, 2001 4:39 PM
> > >
> > > > > > Section 3.5.2
> > > > > > -------------
> > > > > > What the Resource-Owner-NAI AVP used for in the STR? Is it 
> > > > > for routing? I
> > > > > > guess not, since the User-Name AVP is present. Can it be 
> > > > > used in the server
> > > > > > for any particular reason I don't see, since I think the 
> > > > > active session
> > > > > > should be aware of what's going on within itself, right?
> > > > > 
> > > > > If the home server wishes for the NAS to reliquish 
> > > resources, then the
> > > > > User-name AVP doesn't really help since it would cause the 
> > > > > packet to get
> > > > > routed to the home server (loop). So something is needed for 
> > > > > the message to
> > > > > get routed to the NAS, and I envisioned was that the AVP 
> > > > > would be used for
> > > > > routing purposes (and eventually get to the NAS).
> > > > 
> > > > Then, are you telling me that the message routing can be 
> > > done using other
> > > > AVPs than the Routing-Realm AVP and the User-Name AVP? 
> > > Also, is it really
> > > > needed in the STR, which is sent from the access device to 
> > > the Home AAA?
> > > 
> > > In the STR no, only in the STI. Can anyone think of a better 
> > > mechanism? I
> > > really don't know of a better way to do this.
> > 
> > Shouldn't we use the Routing-Realm AVP in order to reach 
> the access device?
> > Then, would you obsolete the Resource-Owner-NAI AVP, or do 
> you see any
> > further need for it? 
> > 
> > My understanding was that the Routing-Realm AVP was the 
> destination of the
> > message, as it is routed through the network, and the 
> Host-Name AVP the
> > originator of the message, which should never change during 
> the message
> > transit to its final destination. However, what could cause 
> problems is the
> > fact that some proxies might modify the Routing-Realm AVP 
> in transit, right?
> 
> I didn't think that Routing-Realm would pin point a 
> particular NAS, but rather
> the domain that it happens to be in. Isn't this your 
> understanding as well?
> 
> PatC
> 

That was my initial understanding until I find out that the Destination-NAI AVP was removed from the Base Protocol. Now, I'm wondering how a re-authentication message can reach the same Host-Server if there is no Destination-NAI AVP in which put the Host-Name AVP of the Home AAA received in the first Authentication response? I thought possible to have several Home servers for the same realm, but since the Destination-NAI AVP was gone, I thought that it would not be possible anymore, unless they all share information about the user session. Could someone help me on that?




From owner-aaa-bof@merit.edu  Tue Jan 23 05:19:25 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08107
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 05:19:25 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id A74225DDBC; Tue, 23 Jan 2001 05:18:19 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 8F9125DDC9; Tue, 23 Jan 2001 05:18:19 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by segue.merit.edu (Postfix) with ESMTP id D253B5DDBC
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 05:18:17 -0500 (EST)
Received: from esealnt462.al.sw.ericsson.se (esealnt462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f0NAIGC14541
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 11:18:16 +0100 (MET)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Jan 23 11:18:17 2001 +0100
Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58)
	id <Z2G92DQQ>; Tue, 23 Jan 2001 11:18:17 +0100
Message-ID: <577066326047D41180AC00508B955DDA01D7FE6A@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        Barney Wolff <barney@databus.com>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec
	tion 3.0
Date: Tue, 23 Jan 2001 11:18:11 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Barney,

I understand you point and I totally agree with you. However, could you please help me with the following scenario? I'd like to know if you would consider it a problem related to the configuration of the Home-AAA server (using policies) or the access device, if the Session-Timeout is reached and forces the servers to release the session? In the case that the timeout is reached in the access device, I could assume that a STR would be sent to the Home-AAA to stop accounting and release the resources in the proxies and the Home-AAA server. However, in the case where the timeout expires in the Home-AAA server, should it stop accounting and release the session immediately, even though you might not be sure that the service has really been terminated in the access device? Also, you might end-up receiving a STR in the Home-AAA with a no longer valid session-ID, right? IMHO, I think DIAMETER should give the tools for assuring user (service) session integrity for the whole network. I!
 hope it is clearer.

BR,
Martin

> -----Original Message-----
> From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com]
> Sent: Monday, January 22, 2001 7:30 PM
> To: Barney Wolff
> Cc: Pat Calhoun; Martin Julien (ECE); 'aaa-wg@merit.edu'
> Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments
> Section 3.0
> 
> 
> Ah, sorry for the misunderstanding. I do agree. Does anyone object?
> 
> PatC
> > I was commenting on language specifying when the server & proxy
> > must release resources (STR/STA).  I don't believe that has to
> > be specified.  All that needs to be said is that a server
> > must respond to STR with STA and a proxy must pass an STA back
> > to its client.  Specifying exactly when internal resources get
> > released is overkill, unless it has consequences on visible
> > behavior.  IMHO.
> > 
> > Barney
> > 
> > On Mon, Jan 22, 2001 at 08:15:26AM -0800, Pat Calhoun wrote:
> > > > Why does DIAMETER need to specify such within-node behavior?
> > > > Is any of it visible outside the node?
> > > 
> > > If state is released implicitly, then a sentence 
> explaining the purpose of the
> > > Session-Timeout AVP is sufficient. However, if explicit 
> signaling is used to
> > > release resources, then it is visible outside the node.
> > > 
> > > PatC
> > > 
> 
> 
> 



From owner-aaa-bof@merit.edu  Tue Jan 23 05:52:44 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08265
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 05:52:44 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id C15285DF24; Tue, 23 Jan 2001 05:49:45 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A45AA5DF21; Tue, 23 Jan 2001 05:49:45 -0500 (EST)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by segue.merit.edu (Postfix) with ESMTP id 2C3E25DE0F
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 05:49:00 -0500 (EST)
Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f0NAmtd25599
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 11:48:55 +0100 (MET)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Jan 23 11:49:44 2001 +0100
Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58)
	id <Z2G92FFD>; Tue, 23 Jan 2001 11:48:55 +0100
Message-ID: <577066326047D41180AC00508B955DDA01D7FE6B@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Pat.Calhoun@eng.sun.com'" <Pat.Calhoun@eng.sun.com>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: [AAA-WG]: DIAMETER Base Protocol (Alpha 1) - Comments section 6.0
Date: Tue, 23 Jan 2001 11:48:43 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Pat,

Some more comments on Alpha1, which I think are still valid for Alpha2. I was waiting before posting it, but since we have already started the discussion about my comments on section 6.2.1 in another thread, I thought I could give it a try.

Martin


Section 6.2.1
-------------
If more than one server is found in the routing table, should the message be sent to all the servers? According to the previous revision of this document, the message should be sent to only one of the servers (refer to section 6.3.1 of draft-calhoun-diameter-17.txt) If so, I wonder how the routing of re-authentication messages from the NAS to the same Home server could occur again for the same session-ID? I thought the no-longer-existing Destination-NAI AVP was meant to identify precisely a destination server within a realm of servers and used as the main key for routing?

Also, I guess the caching of the Home server proposed in the previous version of this document is no longer recommended to short-cut the redirect server? Neither the use of the Session-Timeout AVP?

Section 6.4.2
-------------
"...last Route-Record AVP matches one of its addresses."
Should we replace addresses by Local FQDN, since the Route-Record AVP contains FQDN only?

Section 6.4.4
-------------
Why do we have to specify an address in the Proxy-State if it can not be used for routing anyway? Could we replace it with an Host-Name (FQDN) to make it more consistent with some other AVPs?

Section 6.4.7
-------------
Is the Routing-Realm AVP enough to route a message to a server where a session-ID is already started? I thought the no-longer-existing Destination-NAI AVP was meant to identify precisely a destination server within a realm of servers and used as the main key for routing?

Section 6.7
-----------
"If an AVP with the local host's identity..."
I guess you meant the local host FQDN, as would be used in the Host-Name AVP if a message would origin ate from that proxy?





From owner-aaa-bof@merit.edu  Tue Jan 23 07:49:06 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09836
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 07:49:05 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 912E05DDF2; Tue, 23 Jan 2001 07:45:49 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 7EF605DDCD; Tue, 23 Jan 2001 07:45:49 -0500 (EST)
Received: from cisco.com (pilu.cisco.com [192.122.173.199])
	by segue.merit.edu (Postfix) with ESMTP id A2BA55DDC9
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 07:45:46 -0500 (EST)
Received: (from kaushik@localhost)
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id SAA24045;
	Tue, 23 Jan 2001 18:15:10 +0530 (IST)
From: Kaushik Narayan <kaushik@cisco.com>
Message-Id: <200101231245.SAA24045@cisco.com>
Subject: [AAA-WG]: Re: AAA-WG: RE: Making the hard choices on AAA security
To: Martin.Julien@ece.ericsson.se ("Martin Julien (ECE)")
Date: Tue, 23 Jan 2001 18:15:10 +0530 (IST)
Cc: Pat.Calhoun@Eng.Sun.COM ('Pat.Calhoun@Eng.Sun.COM'),
        aaa-wg@merit.edu ('aaa-wg@merit.edu')
In-Reply-To: <577066326047D41180AC00508B955DDA01D7FE5B@eestqnt104.es.eu.ericsson.se> from "Martin Julien (ECE)" at Jan 19, 2001 08:46:13 AM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

hi!


   End to End security would require three basic components


 1> AVP integrity protection - Select AVPs that need to be inspected by
    intermediate hops but need to be protected against modification
    by intermediate proxies can be integrity protected. The MIC on these
    AVPs would be generated using the end to end key.

 2> AVP encryption - Select AVPs that need to be encrypted can be encrypted
    end to end using the end to end key.

 3> e2e authetication - I am not sure whether per AVP authentication 
    (or Grouped-AVP) would be very efficient since authentication tokens 
    need to be generated and need to carried back and forth. Infact if
    the end to end peers are authenticated and they use a negotiated key to 
    secure AVPs there wouldnot be a need to authenticate individual AVPs. 
    There would be only a need to mutually authenticate the key negotiation
    exchange (initial Request-Response) between the end to end diameter 
    peers.

  kaushik!
  




> 
> I think that authentication on an AVP basis could be an excellent generic solution, and probably not as costly as encryption. However, should it be also allowed to authenticate a group of AVPs, since it seems that the Grouped-AVP AVP, which could contain the group ICV, is gone by now in the -18 document?
> 
> Martin
> 
> -----Original Message-----
> From: Pat Calhoun [mailto:Pat.Calhoun@Eng.Sun.COM]
> Sent: Thursday, January 18, 2001 7:00 PM
> To: Martin Julien (ECE); Steven Glass - Solaris Software;
> 'stephen.farrell@baltimore.ie'
> Cc: aaa-wg@merit.edu; Alain Zahm; Bernard Aboba
> Subject: RE: Making the hard choices on AAA security
> 
> 
> For proxies that wish to maintain state information, not having access
> to the result code would be a problem.
> 
> Perhaps e2e authenticated, but not encrypted.
> 
> PatC
> >Steven,
> >
> >Could we possibly think of allowing the Result-Code AVP to be encrypted for e2e,
> >using the Strong Security extension of course, which would prevent proxies to
> >play around with its content when not allowed by the server?
> >
> >Martin
> >
> >-----Original Message-----
> >From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
> >Sent: Thursday, January 18, 2001 11:16 AM
> >To: Steven Glass - Solaris Software
> >Cc: Bernard Aboba; Alain Zahm; aaa-wg@merit.edu
> >Subject: Re: Making the hard choices on AAA security
> >
> >
> >
> >
> >Steven Glass - Solaris Software wrote:
> >> 
> >> >
> >> >
> >> > > Bernard Aboba wrote:
> >> > >
> >> > > A proxy can change an Access-Accept into an Access-Reject under the guise
> >of "policy". However, an
> >> > > Access-Reject should never be changed to an Access-Accept. A good question
> >is how this could be
> >> > > enforced, using any of the solutions that have been proposed.
> >> >
> >> > Not sure it could...
> >> 
> >>     Maybe not from the solutions proposed...
> >
> >Just for clarity, CMS, Kerberos and any other self-respecting 
> >e2e security solution will offer e2e data integrity. The "not 
> >sure" etc. refers to allowing one type of change and 
> >preventing/detecting another, not to simple integrity.
> >
> >Stephen.
> >
> >-- 
> >____________________________________________________________
> >Stephen Farrell         				   
> >Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> >39 Parkgate Street,                     fax: +353 1 881 7000
> >Dublin 8.                mailto:stephen.farrell@baltimore.ie
> >Ireland                             http://www.baltimore.com
> >
> 
> 
> 




From owner-aaa-bof@merit.edu  Tue Jan 23 09:35:07 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13107
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 09:35:06 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 5B1395DE0E; Tue, 23 Jan 2001 09:34:31 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 49F5B5DDFE; Tue, 23 Jan 2001 09:34:31 -0500 (EST)
Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44])
	by segue.merit.edu (Postfix) with ESMTP id B80985DDC9
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 09:34:29 -0500 (EST)
Received: (from barney@localhost)
	by mx.databus.com (8.11.1/8.11.1) id f0NERxa20049;
	Tue, 23 Jan 2001 09:27:59 -0500 (EST)
	(envelope-from barney)
Date: Tue, 23 Jan 2001 09:27:59 -0500
From: Barney Wolff <barney@databus.com>
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Cc: aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0
Message-ID: <20010123092758.A19972@mx.databus.com>
References: <577066326047D41180AC00508B955DDA01D7FE6A@eestqnt104.es.eu.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <577066326047D41180AC00508B955DDA01D7FE6A@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Tue, Jan 23, 2001 at 11:18:11AM +0100
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Ah, the famous "NAS caught fire" problem.  This is (part of) what
makes server-based resource management hard.  The only solution
that makes sense to me is periodic reassurance from the NAS that
the session is still in progress (aka Interim Accounting).  After
enough time without such assurance, the server has to consider
the resources held by the session to be free again.

You'll see in the Solutions draft discussion of soft state and
hard state - one can use different solutions for "loose"
resources such as IP addresses from a pool and "tight" resources
such as the number of concurrent logins allowed a single user.

I *hate* server-based resource management, but sometimes bosses
and marketeers insist.

Barney

On Tue, Jan 23, 2001 at 11:18:11AM +0100, Martin Julien (ECE) wrote:
> Barney,
> 
> I understand you point and I totally agree with you. However, could you please help me with the following scenario? I'd like to know if you would consider it a problem related to the configuration of the Home-AAA server (using policies) or the access device, if the Session-Timeout is reached and forces the servers to release the session? In the case that the timeout is reached in the access device, I could assume that a STR would be sent to the Home-AAA to stop accounting and release the resources in the proxies and the Home-AAA server. However, in the case where the timeout expires in the Home-AAA server, should it stop accounting and release the session immediately, even though you might not be sure that the service has really been terminated in the access device? Also, you might end-up receiving a STR in the Home-AAA with a no longer valid session-ID, right? IMHO, I think DIAMETER should give the tools for assuring user (service) session integrity for the whole network.!
  I!
>  hope it is clearer.



From owner-aaa-bof@merit.edu  Tue Jan 23 10:22:48 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14686
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 10:22:43 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id ADDDD5DE12; Tue, 23 Jan 2001 10:22:20 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9CF385DDFE; Tue, 23 Jan 2001 10:22:20 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 47E5E5DE0F
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 10:22:19 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA27460;
	Tue, 23 Jan 2001 07:22:09 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA11687;
	Tue, 23 Jan 2001 07:22:08 -0800 (PST)
Received: from cinnamon (cinnamon [129.146.122.100])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA27516;
	Tue, 23 Jan 2001 07:22:06 -0800 (PST)
Date: Tue, 23 Jan 2001 07:21:15 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0
To: Barney Wolff <barney@databus.com>
Cc: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>, aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <20010123092758.A19972@mx.databus.com>
Message-ID: <Roam.SIMC.2.0.6.980263275.9530.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Barney,

So do you agree then that it is possible for entities to simply free their
resources once the timeout has been reached, without the need for explicit
signaling? If the NAS decides to issue the STR, an error will be returned
stating that the session does not exist, at which point it will realize that
the timeout has occured, and free resources anyways.

So is this a problem?

PatC




From owner-aaa-bof@merit.edu  Tue Jan 23 10:33:54 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15000
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 10:33:53 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 179225DE37; Tue, 23 Jan 2001 10:31:18 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 062BB5DE36; Tue, 23 Jan 2001 10:31:18 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id A3BDE5DE21
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 10:31:16 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01027;
	Tue, 23 Jan 2001 07:31:12 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA12864;
	Tue, 23 Jan 2001 07:31:12 -0800 (PST)
Received: from cinnamon (cinnamon [129.146.122.100])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA27594;
	Tue, 23 Jan 2001 07:31:10 -0800 (PST)
Date: Tue, 23 Jan 2001 07:30:18 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 3.0
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Cc: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FE69@eestqnt104.es.eu.ericsson.se>
Message-ID: <Roam.SIMC.2.0.6.980263818.30280.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


> That was my initial understanding until I find out that the Destination-NAI
> AVP was removed from the Base Protocol. Now, I'm wondering how a
> re-authentication message can reach the same Host-Server if there is no
> Destination-NAI AVP in which put the Host-Name AVP of the Home AAA received
> in the first Authentication response? I thought possible to have several
> Home servers for the same realm, but since the Destination-NAI AVP was gone,
> I thought that it would not be possible anymore, unless they all share
> information about the user session. Could someone help me on that?

sigh.

Well I guess in my haste to remove support for different reverse path routing,
I removed an AVP that had additional uses. So, it looks like Destination-NAI
needs to be put back in, but with a much more limited set of functionality. It
will now ONLY be used to identify the host within the domain. The
Routing-Realm AVP is still used to identify the Domain, and once a server
identifies that the message made it to the destination realm, the
Destination-NAI is used to route to a specific host.

This means that the Resource-Owner-NAI is gone.

This seems to work for reverse re-auth *and* termination messages.

Comments?

PatC




From owner-aaa-bof@merit.edu  Tue Jan 23 10:41:45 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15268
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 10:41:45 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id CF2035DE39; Tue, 23 Jan 2001 10:39:19 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id B39F25DE60; Tue, 23 Jan 2001 10:39:19 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id AF6D15DE39
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 10:38:38 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00743
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 07:38:38 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA14086
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 07:38:37 -0800 (PST)
Received: from cinnamon (cinnamon [129.146.122.100])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA27694
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 07:38:36 -0800 (PST)
Date: Tue, 23 Jan 2001 07:37:44 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: [AAA-WG]: Proposed ABNF message definition
To: aaa-wg@merit.edu
Message-ID: <Roam.SIMC.2.0.6.980264264.11192.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

All,

I would like to solicit comments on modifying the first round of DIAMETER
specs as WG documents to make use of Erik's proposed ABNF format. These are
MUCH better than what is currently in the document, and we can always change
them to a different format in a future revision.

Any objections before I move forward with the changes?

PatC




From owner-aaa-bof@merit.edu  Tue Jan 23 11:30:19 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16704
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 11:30:19 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id AE21D5DE3A; Tue, 23 Jan 2001 11:29:50 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 91EE05DE32; Tue, 23 Jan 2001 11:29:50 -0500 (EST)
Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44])
	by segue.merit.edu (Postfix) with ESMTP id 2D34F5DE21
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 11:29:49 -0500 (EST)
Received: (from barney@localhost)
	by mx.databus.com (8.11.1/8.11.1) id f0NGTYw20722;
	Tue, 23 Jan 2001 11:29:34 -0500 (EST)
	(envelope-from barney)
Date: Tue, 23 Jan 2001 11:29:33 -0500
From: Barney Wolff <barney@databus.com>
To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Cc: Barney Wolff <barney@databus.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0
Message-ID: <20010123112933.A20613@mx.databus.com>
References: <20010123092758.A19972@mx.databus.com> <Roam.SIMC.2.0.6.980263275.9530.pcalhoun@nasnfs>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Roam.SIMC.2.0.6.980263275.9530.pcalhoun@nasnfs>; from Pat.Calhoun@Eng.Sun.COM on Tue, Jan 23, 2001 at 07:21:15AM -0800
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

I think it's a little more complex.  A session-limiting timeout
from server to NAS should certainly provoke an STR from the server
when the time runs out.  The only time a node would silently drop
a session is when a server has sent a session-timeout at the start,
and fails to hear anything from the NAS after a well-chosen interval.
That could be some increment over the interim accounting interval,
if interim accounting is in use, or the session timeout, if that
was specified.  That silent drop assumes the server has no way to
signal or probe the NAS, as was true for RADIUS.

With DIAMETER, a server in that state should send an STR towards
the NAS rather than just silently drop its resources, as long as
such an STR is allowed.  That's a no-lose step - if the NAS has
silently restarted, the server will get some response indicating
that.  If the NAS is dead, the server will get a response from
a proxy, or at least time out after a relatively short wait.

I can imagine cases where it's more complex yet, when part of
the chain is DIAMETER and part is RADIUS.  There we need a
way for a proxy to say "cannot translate".

I'm sorry if I've been unclear in expression, or just muddled in
thinking.  Saying that we don't need to specify WHEN a node frees
resources was not intended to imply that a DIAMETER peer should
be silent when its partner fails to send an expected request or
response.

Barney

On Tue, Jan 23, 2001 at 07:21:15AM -0800, Pat Calhoun wrote:
> Barney,
> 
> So do you agree then that it is possible for entities to simply free their
> resources once the timeout has been reached, without the need for explicit
> signaling? If the NAS decides to issue the STR, an error will be returned
> stating that the session does not exist, at which point it will realize that
> the timeout has occured, and free resources anyways.
> 
> So is this a problem?
> 
> PatC
> 



From owner-aaa-bof@merit.edu  Tue Jan 23 11:41:10 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16990
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 11:41:10 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 055A75DE32; Tue, 23 Jan 2001 11:40:52 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id E7F7D5DE2D; Tue, 23 Jan 2001 11:40:51 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 9883D5DE20
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 11:40:50 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22423;
	Tue, 23 Jan 2001 08:40:46 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA15010;
	Tue, 23 Jan 2001 08:40:46 -0800 (PST)
Received: from cinnamon (cinnamon [129.146.122.100])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA28169;
	Tue, 23 Jan 2001 08:40:44 -0800 (PST)
Date: Tue, 23 Jan 2001 08:39:50 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0
To: Barney Wolff <barney@databus.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <20010123112933.A20613@mx.databus.com>
Message-ID: <Roam.SIMC.2.0.6.980267990.17463.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Cool, I think we are nearly there. One more question. Who initiates the STR?
Should it be the NAS, or the home server. We need to provide some guidelines
to reduce the changes of such messages crossing through the network.

PatC




From owner-aaa-bof@merit.edu  Tue Jan 23 12:44:41 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19046
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 12:44:41 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 0A6BB5DE2D; Tue, 23 Jan 2001 12:44:07 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id ECE735DE20; Tue, 23 Jan 2001 12:44:06 -0500 (EST)
Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110])
	by segue.merit.edu (Postfix) with ESMTP id 16D075DDF1
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 12:44:06 -0500 (EST)
Received: from Interlinknetworks.com (unknown [198.108.5.3])
	by aaa.interlinknetworks.com (Postfix) with ESMTP
	id D075F72; Tue, 23 Jan 2001 12:44:14 -0500 (EST)
Message-ID: <3A6DC2FF.C8F4328C@Interlinknetworks.com>
Date: Tue, 23 Jan 2001 12:44:31 -0500
From: David Spence <DSpence@Interlinknetworks.com>
Organization: Interlink Networks, Inc.
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: Barney Wolff <barney@databus.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 
 3.0
References: <Roam.SIMC.2.0.6.980267990.17463.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat Calhoun wrote:
> 
> Cool, I think we are nearly there. One more question. Who initiates the STR?
> Should it be the NAS, or the home server. We need to provide some guidelines
> to reduce the changes of such messages crossing through the network.
> 
> PatC

I guess I'm confused as to where "there" is.  I hear Barney and Martin
aguing for explicit signalling and Pat arguing that timeouts themselves
should terminate sessions without the need for signalling.

Personally, I think that all terminations should be explicitly signalled. 
We need to carefully consider all of the possible collision scenarios.  Not
signalling doesn't really simplify things.  For example, the home server may
time out just as the NAS is simultaneously sending a re-auth.  (I realize
the NAS should have sent the re-auth earlier, but delays do happen.)  When
the home server receives the re-auth, it gets confused because it has
already released state.  If the home server had sent an STI and waited for
an STR, then things like the re-auth collision could be handled better.  To
get this right, we really need to specify a session state table.  That's
more work, but it's part of making a good standard.

I also have a comment on the idea of including an Extension-ID AVP in STRs
and STIs.  I can understand the desire to be able to terminate subsessions
of a complex session, but DIAMETER doesn't really support subsessions.  I
can also understand the need to free some resources within a session without
terminating the entire session.  But to do that, you need real resource
management, and DIAMETER doesn't do that either.  I don't think trying to do
pseudo-resouce management through the use of the Extension-ID AVP is a
particularly good idea.  The Extension-ID does not really indicate
resources, nor does it precisely indicate applications either.  Instead it
simply indicates which subsets of DIAMETER are being used in the protocol
exchange.  So what would it mean if a server receives an STR (or STI)
specifying some Session-ID and the NASREQ Extension-ID, but not the
Strong-Crypto Extension-ID which was also used in establishing the session? 
Or if a server receives an STR specifying the Accounting Extension-ID but
not the NASREQ Extension-ID (although maybe we've decided to include
accounting in the service extensions)?

Anyway, I think if we want to do resource management, then we should figure
out how to do resource management and not try to slap together a quick fix
that uses the wrong data element for the wrong purpose.  Personally, I would
be quite happy if we left the STRs and STIs the way they are and let them
terminate an entire session -- all resources and state associated with a
Session-ID.

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



From owner-aaa-bof@merit.edu  Tue Jan 23 13:29:49 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20356
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 13:29:48 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id E4F725DE36; Tue, 23 Jan 2001 13:29:27 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id D37665DE26; Tue, 23 Jan 2001 13:29:27 -0500 (EST)
Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44])
	by segue.merit.edu (Postfix) with ESMTP id 577B55DDF1
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 13:29:26 -0500 (EST)
Received: (from barney@localhost)
	by mx.databus.com (8.11.1/8.11.1) id f0NITIs21226;
	Tue, 23 Jan 2001 13:29:18 -0500 (EST)
	(envelope-from barney)
Date: Tue, 23 Jan 2001 13:29:18 -0500
From: Barney Wolff <barney@databus.com>
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: Barney Wolff <barney@databus.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0
Message-ID: <20010123132918.A21181@mx.databus.com>
References: <20010123112933.A20613@mx.databus.com> <Roam.SIMC.2.0.6.980267990.17463.pcalhoun@nasnfs>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Roam.SIMC.2.0.6.980267990.17463.pcalhoun@nasnfs>; from Pat.Calhoun@eng.sun.com on Tue, Jan 23, 2001 at 08:39:50AM -0800
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

I'd say the NAS does it, as it should have the primary timing
responsibility.  The server's timing is to avoid getting stuck in
a state, and can be quite coarse, or nonexistent if the server
does not track session state.

If the server had the primary
timing responsibility, we wouldn't need the session-timout avp at
all, as it could just decide to terminate the session when it wants
to.  But I think that's a poor use of server cycles.

Barney

On Tue, Jan 23, 2001 at 08:39:50AM -0800, Pat Calhoun wrote:
> Cool, I think we are nearly there. One more question. Who initiates the STR?
> Should it be the NAS, or the home server. We need to provide some guidelines
> to reduce the changes of such messages crossing through the network.
> 
> PatC
> 
> 



From owner-aaa-bof@merit.edu  Tue Jan 23 13:49:09 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20817
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 13:49:08 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 75F6D5DEC9; Tue, 23 Jan 2001 13:46:35 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 600AA5DED0; Tue, 23 Jan 2001 13:46:35 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 0D65B5DEC9
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 13:46:34 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07520;
	Tue, 23 Jan 2001 10:43:31 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA11827;
	Tue, 23 Jan 2001 09:56:12 -0800 (PST)
Received: from cinnamon (cinnamon [129.146.122.100])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA29312;
	Tue, 23 Jan 2001 09:56:09 -0800 (PST)
Date: Tue, 23 Jan 2001 09:55:02 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion  3.0
To: David Spence <DSpence@Interlinknetworks.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>, Barney Wolff <barney@databus.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <3A6DC2FF.C8F4328C@Interlinknetworks.com>
Message-ID: <Roam.SIMC.2.0.6.980272502.15441.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Pat Calhoun wrote:
> > 
> > Cool, I think we are nearly there. One more question. Who initiates the STR?
> > Should it be the NAS, or the home server. We need to provide some guidelines
> > to reduce the changes of such messages crossing through the network.
> > 
> > PatC
> 
> I guess I'm confused as to where "there" is.  I hear Barney and Martin
> aguing for explicit signalling and Pat arguing that timeouts themselves
> should terminate sessions without the need for signalling.

ok, perhaps I didn't make myself that clear. I am in agreement with Barney and
Martin, which led to my question.

> 
> Personally, I think that all terminations should be explicitly signalled. 
> We need to carefully consider all of the possible collision scenarios.  Not
> signalling doesn't really simplify things.  For example, the home server may
> time out just as the NAS is simultaneously sending a re-auth.  (I realize
> the NAS should have sent the re-auth earlier, but delays do happen.)  When
> the home server receives the re-auth, it gets confused because it has
> already released state.  If the home server had sent an STI and waited for
> an STR, then things like the re-auth collision could be handled better.  To
> get this right, we really need to specify a session state table.  That's
> more work, but it's part of making a good standard.

So, if I understand correctly, a new state table needs to be provided to show
the state transitions of a session, correct?

Any comment on who should initiate the STR or STI? Could we say that if a
session is terminated due to a session timeout, the NAS does it. However, if
the home server does not receive the STR within session timeout + fudge
factor, then it should send the STI. Of course, either peer is entitled to
send the STR at any time prior to the session timeout.

does this work?

> 
> I also have a comment on the idea of including an Extension-ID AVP in STRs
> and STIs.  I can understand the desire to be able to terminate subsessions
> of a complex session, but DIAMETER doesn't really support subsessions.  I
> can also understand the need to free some resources within a session without
> terminating the entire session.  But to do that, you need real resource
> management, and DIAMETER doesn't do that either.  I don't think trying to do
> pseudo-resouce management through the use of the Extension-ID AVP is a
> particularly good idea.  The Extension-ID does not really indicate
> resources, nor does it precisely indicate applications either.  Instead it
> simply indicates which subsets of DIAMETER are being used in the protocol
> exchange.  So what would it mean if a server receives an STR (or STI)
> specifying some Session-ID and the NASREQ Extension-ID, but not the
> Strong-Crypto Extension-ID which was also used in establishing the session? 
> Or if a server receives an STR specifying the Accounting Extension-ID but
> not the NASREQ Extension-ID (although maybe we've decided to include
> accounting in the service extensions)?

Good argument against extension ID in STRs.

> 
> Anyway, I think if we want to do resource management, then we should figure
> out how to do resource management and not try to slap together a quick fix
> that uses the wrong data element for the wrong purpose.  Personally, I would
> be quite happy if we left the STRs and STIs the way they are and let them
> terminate an entire session -- all resources and state associated with a
> Session-ID.

ok, that works for me as well, since it is the easiest (both in terms of
documentation as well as implementation).

PatC




From owner-aaa-bof@merit.edu  Tue Jan 23 13:50:14 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20926
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 13:50:14 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id BC3885DE3F; Tue, 23 Jan 2001 13:48:21 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A5C9B5DE60; Tue, 23 Jan 2001 13:48:21 -0500 (EST)
Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110])
	by segue.merit.edu (Postfix) with ESMTP id B834E5DE3F
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 13:48:20 -0500 (EST)
Received: from Interlinknetworks.com (unknown [198.108.5.3])
	by aaa.interlinknetworks.com (Postfix) with ESMTP
	id 4D57072; Tue, 23 Jan 2001 13:48:29 -0500 (EST)
Message-ID: <3A6DD20B.B387F097@Interlinknetworks.com>
Date: Tue, 23 Jan 2001 13:48:43 -0500
From: David Spence <DSpence@Interlinknetworks.com>
Organization: Interlink Networks, Inc.
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Barney Wolff <barney@databus.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 
 3.0
References: <20010123112933.A20613@mx.databus.com> <Roam.SIMC.2.0.6.980267990.17463.pcalhoun@nasnfs> <20010123132918.A21181@mx.databus.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Actually, both the NAS and the home server have to run a timer.  The home
server has to because he's the one who cares and he wants to enforce his
policy.  The NAS has to because it is possible that the home server will be
(temporarily) unreachable from the NAS at the time the timeout is to occur. 
The NAS has an interest in running the timer because if the home
organization will refuse to pay for a longer session than the timeout
specifies, then the NAS wants to make sure it doesn't provide a longer
session.

This means that both parties will timeout approximately simultaneously so a
termination collision is likely.  No problem.  The home server is expecting
an STR in response to its STI, so if it receives the STR generated by the
NAS' timeout, its happy.  The rule for the NAS is: ignore an STI received in
STR-sent state.  So the NAS avoids sending a second STR.  The home server
will send STA in response to STR and everyone is happy.

Barney Wolff wrote:
> 
> I'd say the NAS does it, as it should have the primary timing
> responsibility.  The server's timing is to avoid getting stuck in
> a state, and can be quite coarse, or nonexistent if the server
> does not track session state.
> 
> If the server had the primary
> timing responsibility, we wouldn't need the session-timout avp at
> all, as it could just decide to terminate the session when it wants
> to.  But I think that's a poor use of server cycles.
> 
> Barney
> 
> On Tue, Jan 23, 2001 at 08:39:50AM -0800, Pat Calhoun wrote:
> > Cool, I think we are nearly there. One more question. Who initiates the STR?
> > Should it be the NAS, or the home server. We need to provide some guidelines
> > to reduce the changes of such messages crossing through the network.
> >
> > PatC
> >
> >

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



From owner-aaa-bof@merit.edu  Tue Jan 23 13:53:02 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20983
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 13:53:01 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 5EA555DE4E; Tue, 23 Jan 2001 13:52:42 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 3AE795DE4B; Tue, 23 Jan 2001 13:52:42 -0500 (EST)
Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110])
	by segue.merit.edu (Postfix) with ESMTP id 8D3B75DE4A
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 13:52:40 -0500 (EST)
Received: from Interlinknetworks.com (unknown [198.108.5.3])
	by aaa.interlinknetworks.com (Postfix) with ESMTP
	id 5EB2A72; Tue, 23 Jan 2001 13:52:49 -0500 (EST)
Message-ID: <3A6DD30F.33776BEF@Interlinknetworks.com>
Date: Tue, 23 Jan 2001 13:53:03 -0500
From: David Spence <DSpence@Interlinknetworks.com>
Organization: Interlink Networks, Inc.
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: Barney Wolff <barney@databus.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion  
 3.0
References: <Roam.SIMC.2.0.6.980272502.15441.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

See comments interspersed below.

Pat Calhoun wrote:
> 
> > Pat Calhoun wrote:
> > >
> > > Cool, I think we are nearly there. One more question. Who initiates the STR?
> > > Should it be the NAS, or the home server. We need to provide some guidelines
> > > to reduce the changes of such messages crossing through the network.
> > >
> > > PatC
> >
> > I guess I'm confused as to where "there" is.  I hear Barney and Martin
> > aguing for explicit signalling and Pat arguing that timeouts themselves
> > should terminate sessions without the need for signalling.
> 
> ok, perhaps I didn't make myself that clear. I am in agreement with Barney and
> Martin, which led to my question.

Good.  Now I understand.

> 
> >
> > Personally, I think that all terminations should be explicitly signalled.
> > We need to carefully consider all of the possible collision scenarios.  Not
> > signalling doesn't really simplify things.  For example, the home server may
> > time out just as the NAS is simultaneously sending a re-auth.  (I realize
> > the NAS should have sent the re-auth earlier, but delays do happen.)  When
> > the home server receives the re-auth, it gets confused because it has
> > already released state.  If the home server had sent an STI and waited for
> > an STR, then things like the re-auth collision could be handled better.  To
> > get this right, we really need to specify a session state table.  That's
> > more work, but it's part of making a good standard.
> 
> So, if I understand correctly, a new state table needs to be provided to show
> the state transitions of a session, correct?
> 
> Any comment on who should initiate the STR or STI? Could we say that if a
> session is terminated due to a session timeout, the NAS does it. However, if
> the home server does not receive the STR within session timeout + fudge
> factor, then it should send the STI. Of course, either peer is entitled to
> send the STR at any time prior to the session timeout.
> 
> does this work?

See my reply of a few minutes ago to Barney Wolff for an informal
description of how I think it should work.

> 
> >
> > I also have a comment on the idea of including an Extension-ID AVP in STRs
> > and STIs.  I can understand the desire to be able to terminate subsessions
> > of a complex session, but DIAMETER doesn't really support subsessions.  I
> > can also understand the need to free some resources within a session without
> > terminating the entire session.  But to do that, you need real resource
> > management, and DIAMETER doesn't do that either.  I don't think trying to do
> > pseudo-resouce management through the use of the Extension-ID AVP is a
> > particularly good idea.  The Extension-ID does not really indicate
> > resources, nor does it precisely indicate applications either.  Instead it
> > simply indicates which subsets of DIAMETER are being used in the protocol
> > exchange.  So what would it mean if a server receives an STR (or STI)
> > specifying some Session-ID and the NASREQ Extension-ID, but not the
> > Strong-Crypto Extension-ID which was also used in establishing the session?
> > Or if a server receives an STR specifying the Accounting Extension-ID but
> > not the NASREQ Extension-ID (although maybe we've decided to include
> > accounting in the service extensions)?
> 
> Good argument against extension ID in STRs.
> 
> >
> > Anyway, I think if we want to do resource management, then we should figure
> > out how to do resource management and not try to slap together a quick fix
> > that uses the wrong data element for the wrong purpose.  Personally, I would
> > be quite happy if we left the STRs and STIs the way they are and let them
> > terminate an entire session -- all resources and state associated with a
> > Session-ID.
> 
> ok, that works for me as well, since it is the easiest (both in terms of
> documentation as well as implementation).
> 
> PatC

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



From owner-aaa-bof@merit.edu  Tue Jan 23 13:53:27 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21007
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 13:53:27 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 445EB5DDF1; Tue, 23 Jan 2001 13:53:01 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 1697D5DE51; Tue, 23 Jan 2001 13:53:01 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id C4E9F5DDF1
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 13:52:56 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19445;
	Tue, 23 Jan 2001 10:52:51 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA24023;
	Tue, 23 Jan 2001 10:52:50 -0800 (PST)
Received: from cinnamon (cinnamon [129.146.122.100])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA00568;
	Tue, 23 Jan 2001 10:52:38 -0800 (PST)
Date: Tue, 23 Jan 2001 10:51:46 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion  3.0
To: David Spence <DSpence@Interlinknetworks.com>
Cc: Barney Wolff <barney@databus.com>, Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <3A6DD20B.B387F097@Interlinknetworks.com>
Message-ID: <Roam.SIMC.2.0.6.980275906.9925.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Simple state machine. I like it.

PatC
> Actually, both the NAS and the home server have to run a timer.  The home
> server has to because he's the one who cares and he wants to enforce his
> policy.  The NAS has to because it is possible that the home server will be
> (temporarily) unreachable from the NAS at the time the timeout is to occur. 
> The NAS has an interest in running the timer because if the home
> organization will refuse to pay for a longer session than the timeout
> specifies, then the NAS wants to make sure it doesn't provide a longer
> session.
> 
> This means that both parties will timeout approximately simultaneously so a
> termination collision is likely.  No problem.  The home server is expecting
> an STR in response to its STI, so if it receives the STR generated by the
> NAS' timeout, its happy.  The rule for the NAS is: ignore an STI received in
> STR-sent state.  So the NAS avoids sending a second STR.  The home server
> will send STA in response to STR and everyone is happy.
> 
> Barney Wolff wrote:
> > 
> > I'd say the NAS does it, as it should have the primary timing
> > responsibility.  The server's timing is to avoid getting stuck in
> > a state, and can be quite coarse, or nonexistent if the server
> > does not track session state.
> > 
> > If the server had the primary
> > timing responsibility, we wouldn't need the session-timout avp at
> > all, as it could just decide to terminate the session when it wants
> > to.  But I think that's a poor use of server cycles.
> > 
> > Barney
> > 
> > On Tue, Jan 23, 2001 at 08:39:50AM -0800, Pat Calhoun wrote:
> > > Cool, I think we are nearly there. One more question. Who initiates the STR?
> > > Should it be the NAS, or the home server. We need to provide some guidelines
> > > to reduce the changes of such messages crossing through the network.
> > >
> > > PatC
> > >
> > >
> 
> -- 
> David Spence                            email: DSpence@Interlinknetworks.com
> Interlink Networks, Inc.                phone: (734) 821-1203
> 775 Technology Drive, Suite 200         fax:   (734) 821-1235
> Ann Arbor, MI 48108           
> U.S.A.





From owner-aaa-bof@merit.edu  Tue Jan 23 14:02:58 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21468
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 14:02:57 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 447895DE51; Tue, 23 Jan 2001 14:00:22 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 00BB45DE4B; Tue, 23 Jan 2001 14:00:20 -0500 (EST)
Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44])
	by segue.merit.edu (Postfix) with ESMTP id B68B25DE55
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 14:00:16 -0500 (EST)
Received: (from barney@localhost)
	by mx.databus.com (8.11.1/8.11.1) id f0NJ05g21492;
	Tue, 23 Jan 2001 14:00:05 -0500 (EST)
	(envelope-from barney)
Date: Tue, 23 Jan 2001 14:00:05 -0500
From: Barney Wolff <barney@databus.com>
To: David Spence <DSpence@Interlinknetworks.com>
Cc: Barney Wolff <barney@databus.com>, Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0
Message-ID: <20010123140004.A21418@mx.databus.com>
References: <20010123112933.A20613@mx.databus.com> <Roam.SIMC.2.0.6.980267990.17463.pcalhoun@nasnfs> <20010123132918.A21181@mx.databus.com> <3A6DD20B.B387F097@Interlinknetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <3A6DD20B.B387F097@Interlinknetworks.com>; from DSpence@Interlinknetworks.com on Tue, Jan 23, 2001 at 01:48:43PM -0500
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

I do not think the home server has to run a fine-grained timer,
or any timer at all if it is not doing resource management.
It can do fine-grained timing, if it's anal, but we MUST NOT :)
make it a MUST.

Barney

On Tue, Jan 23, 2001 at 01:48:43PM -0500, David Spence wrote:
> Actually, both the NAS and the home server have to run a timer.  The home
> server has to because he's the one who cares and he wants to enforce his
> policy.  The NAS has to because it is possible that the home server will be
> (temporarily) unreachable from the NAS at the time the timeout is to occur. 
> The NAS has an interest in running the timer because if the home
> organization will refuse to pay for a longer session than the timeout
> specifies, then the NAS wants to make sure it doesn't provide a longer
> session.
> 
> This means that both parties will timeout approximately simultaneously so a
> termination collision is likely.  No problem.  The home server is expecting
> an STR in response to its STI, so if it receives the STR generated by the
> NAS' timeout, its happy.  The rule for the NAS is: ignore an STI received in
> STR-sent state.  So the NAS avoids sending a second STR.  The home server
> will send STA in response to STR and everyone is happy.
> 
> Barney Wolff wrote:
> > 
> > I'd say the NAS does it, as it should have the primary timing
> > responsibility.  The server's timing is to avoid getting stuck in
> > a state, and can be quite coarse, or nonexistent if the server
> > does not track session state.
> > 
> > If the server had the primary
> > timing responsibility, we wouldn't need the session-timout avp at
> > all, as it could just decide to terminate the session when it wants
> > to.  But I think that's a poor use of server cycles.
> > 
> > Barney
> > 
> > On Tue, Jan 23, 2001 at 08:39:50AM -0800, Pat Calhoun wrote:
> > > Cool, I think we are nearly there. One more question. Who initiates the STR?
> > > Should it be the NAS, or the home server. We need to provide some guidelines
> > > to reduce the changes of such messages crossing through the network.
> > >
> > > PatC
> > >
> > >
> 
> -- 
> David Spence                            email: DSpence@Interlinknetworks.com
> Interlink Networks, Inc.                phone: (734) 821-1203
> 775 Technology Drive, Suite 200         fax:   (734) 821-1235
> Ann Arbor, MI 48108           
> U.S.A.



From owner-aaa-bof@merit.edu  Tue Jan 23 14:06:31 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21580
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 14:06:30 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id A6BED5DE5D; Tue, 23 Jan 2001 14:04:14 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 93B2F5DE5B; Tue, 23 Jan 2001 14:04:14 -0500 (EST)
Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110])
	by segue.merit.edu (Postfix) with ESMTP id 55BB95DE55
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 14:04:13 -0500 (EST)
Received: from Interlinknetworks.com (unknown [198.108.5.3])
	by aaa.interlinknetworks.com (Postfix) with ESMTP
	id 2219173; Tue, 23 Jan 2001 14:04:22 -0500 (EST)
Message-ID: <3A6DD5C3.A2E2E27A@Interlinknetworks.com>
Date: Tue, 23 Jan 2001 14:04:35 -0500
From: David Spence <DSpence@Interlinknetworks.com>
Organization: Interlink Networks, Inc.
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Barney Wolff <barney@databus.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 
 3.0
References: <20010123112933.A20613@mx.databus.com> <Roam.SIMC.2.0.6.980267990.17463.pcalhoun@nasnfs> <20010123132918.A21181@mx.databus.com> <3A6DD20B.B387F097@Interlinknetworks.com> <20010123140004.A21418@mx.databus.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I'm o.k. with making it a MUST for the NAS and a MAY for the home server. 
If the protocol is specified as I've proposed, it should work either way.

Barney Wolff wrote:
> 
> I do not think the home server has to run a fine-grained timer,
> or any timer at all if it is not doing resource management.
> It can do fine-grained timing, if it's anal, but we MUST NOT :)
> make it a MUST.
> 
> Barney
> 
> On Tue, Jan 23, 2001 at 01:48:43PM -0500, David Spence wrote:
> > Actually, both the NAS and the home server have to run a timer.  The home
> > server has to because he's the one who cares and he wants to enforce his
> > policy.  The NAS has to because it is possible that the home server will be
> > (temporarily) unreachable from the NAS at the time the timeout is to occur.
> > The NAS has an interest in running the timer because if the home
> > organization will refuse to pay for a longer session than the timeout
> > specifies, then the NAS wants to make sure it doesn't provide a longer
> > session.
> >
> > This means that both parties will timeout approximately simultaneously so a
> > termination collision is likely.  No problem.  The home server is expecting
> > an STR in response to its STI, so if it receives the STR generated by the
> > NAS' timeout, its happy.  The rule for the NAS is: ignore an STI received in
> > STR-sent state.  So the NAS avoids sending a second STR.  The home server
> > will send STA in response to STR and everyone is happy.
> >
> > Barney Wolff wrote:
> > >
> > > I'd say the NAS does it, as it should have the primary timing
> > > responsibility.  The server's timing is to avoid getting stuck in
> > > a state, and can be quite coarse, or nonexistent if the server
> > > does not track session state.
> > >
> > > If the server had the primary
> > > timing responsibility, we wouldn't need the session-timout avp at
> > > all, as it could just decide to terminate the session when it wants
> > > to.  But I think that's a poor use of server cycles.
> > >
> > > Barney
> > >
> > > On Tue, Jan 23, 2001 at 08:39:50AM -0800, Pat Calhoun wrote:
> > > > Cool, I think we are nearly there. One more question. Who initiates the STR?
> > > > Should it be the NAS, or the home server. We need to provide some guidelines
> > > > to reduce the changes of such messages crossing through the network.
> > > >
> > > > PatC
> > > >
> > > >
> >
> > --
> > David Spence                            email: DSpence@Interlinknetworks.com
> > Interlink Networks, Inc.                phone: (734) 821-1203
> > 775 Technology Drive, Suite 200         fax:   (734) 821-1235
> > Ann Arbor, MI 48108
> > U.S.A.

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



From owner-aaa-bof@merit.edu  Tue Jan 23 14:07:56 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21660
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 14:07:55 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id CA3165DE4B; Tue, 23 Jan 2001 14:07:20 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id B86A05DE4A; Tue, 23 Jan 2001 14:07:20 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 932015DE30
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 14:07:19 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01397;
	Tue, 23 Jan 2001 11:06:56 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA28188;
	Tue, 23 Jan 2001 11:06:55 -0800 (PST)
Received: from cinnamon (cinnamon [129.146.122.100])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id LAA00800;
	Tue, 23 Jan 2001 11:06:40 -0800 (PST)
Date: Tue, 23 Jan 2001 11:05:46 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion  3.0
To: David Spence <DSpence@Interlinknetworks.com>
Cc: Barney Wolff <barney@databus.com>, Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <3A6DD5C3.A2E2E27A@Interlinknetworks.com>
Message-ID: <Roam.SIMC.2.0.6.980276746.18153.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Good, so NAS MUST sent STR, home server MAY sent STI. race conditions are
handled by the NAS.

I'll have text written up later today to represent the session state machine.

PatC
> I'm o.k. with making it a MUST for the NAS and a MAY for the home server. 
> If the protocol is specified as I've proposed, it should work either way.
> 
> Barney Wolff wrote:
> > 
> > I do not think the home server has to run a fine-grained timer,
> > or any timer at all if it is not doing resource management.
> > It can do fine-grained timing, if it's anal, but we MUST NOT :)
> > make it a MUST.
> > 
> > Barney
> > 
> > On Tue, Jan 23, 2001 at 01:48:43PM -0500, David Spence wrote:
> > > Actually, both the NAS and the home server have to run a timer.  The home
> > > server has to because he's the one who cares and he wants to enforce his
> > > policy.  The NAS has to because it is possible that the home server will be
> > > (temporarily) unreachable from the NAS at the time the timeout is to occur.
> > > The NAS has an interest in running the timer because if the home
> > > organization will refuse to pay for a longer session than the timeout
> > > specifies, then the NAS wants to make sure it doesn't provide a longer
> > > session.
> > >
> > > This means that both parties will timeout approximately simultaneously so a
> > > termination collision is likely.  No problem.  The home server is expecting
> > > an STR in response to its STI, so if it receives the STR generated by the
> > > NAS' timeout, its happy.  The rule for the NAS is: ignore an STI received in
> > > STR-sent state.  So the NAS avoids sending a second STR.  The home server
> > > will send STA in response to STR and everyone is happy.
> > >
> > > Barney Wolff wrote:
> > > >
> > > > I'd say the NAS does it, as it should have the primary timing
> > > > responsibility.  The server's timing is to avoid getting stuck in
> > > > a state, and can be quite coarse, or nonexistent if the server
> > > > does not track session state.
> > > >
> > > > If the server had the primary
> > > > timing responsibility, we wouldn't need the session-timout avp at
> > > > all, as it could just decide to terminate the session when it wants
> > > > to.  But I think that's a poor use of server cycles.
> > > >
> > > > Barney
> > > >
> > > > On Tue, Jan 23, 2001 at 08:39:50AM -0800, Pat Calhoun wrote:
> > > > > Cool, I think we are nearly there. One more question. Who initiates the STR?
> > > > > Should it be the NAS, or the home server. We need to provide some guidelines
> > > > > to reduce the changes of such messages crossing through the network.
> > > > >
> > > > > PatC
> > > > >
> > > > >
> > >
> > > --
> > > David Spence                            email: DSpence@Interlinknetworks.com
> > > Interlink Networks, Inc.                phone: (734) 821-1203
> > > 775 Technology Drive, Suite 200         fax:   (734) 821-1235
> > > Ann Arbor, MI 48108
> > > U.S.A.
> 
> -- 
> David Spence                            email: DSpence@Interlinknetworks.com
> Interlink Networks, Inc.                phone: (734) 821-1203
> 775 Technology Drive, Suite 200         fax:   (734) 821-1235
> Ann Arbor, MI 48108           
> U.S.A.





From owner-aaa-bof@merit.edu  Tue Jan 23 14:50:17 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22954
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 14:50:17 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 137675DED8; Tue, 23 Jan 2001 14:48:20 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 020335DED5; Tue, 23 Jan 2001 14:48:19 -0500 (EST)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by segue.merit.edu (Postfix) with ESMTP id 765B95DE61
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 14:48:18 -0500 (EST)
Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f0NJmEK26019;
	Tue, 23 Jan 2001 13:48:14 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id f0NJiYr22662;
	Tue, 23 Jan 2001 13:44:34 -0600 (CST)
Received: from qpop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA19946; Tue, 23 Jan 2001 13:48:11 -0600 (CST)
Received: from ericsson.com (busam70.berkeley.us.am.ericsson.se [138.85.159.220])
	by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA12039;
	Tue, 23 Jan 2001 13:48:08 -0600 (CST)
Message-ID: <3A6DE01C.A7794FB5@ericsson.com>
Date: Tue, 23 Jan 2001 11:48:44 -0800
From: Tony Johansson <tony.johansson@ericsson.com>
Organization: Ericsson Inc
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>, Martin.Julien@ece.ericsson.se
Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section 
 3.0
References: <Roam.SIMC.2.0.6.980263818.30280.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pat,

See comments embedded....

BR,

/Tony

Pat Calhoun wrote:

> > That was my initial understanding until I find out that the Destination-NAI
> > AVP was removed from the Base Protocol. Now, I'm wondering how a
> > re-authentication message can reach the same Host-Server if there is no
> > Destination-NAI AVP in which put the Host-Name AVP of the Home AAA received
> > in the first Authentication response? I thought possible to have several
> > Home servers for the same realm, but since the Destination-NAI AVP was gone,
> > I thought that it would not be possible anymore, unless they all share
> > information about the user session. Could someone help me on that?

> sigh.

Well, first of all the Destination-NAI AVP was never intended to be used as
described above, right?!. The Host-Name contains the originating host (i.e. the
NAS or the FA) and the Host-Name AVP was copied into the Destination-NAI AVP for
the return trip. The Destination-NAI AVP was then used to route the reply message
back to the originating host. Correct ?

>
>
> Well I guess in my haste to remove support for different reverse path routing,
> I removed an AVP that had additional uses.

What additional uses do you recall ?

> So, it looks like Destination-NAI
> needs to be put back in, but with a much more limited set of functionality. It
> will now ONLY be used to identify the host within the domain. The
> Routing-Realm AVP is still used to identify the Domain, and once a server
> identifies that the message made it to the destination realm, the
> Destination-NAI is used to route to a specific host.

I'm not sure that I understand why we need this. Is it to allow a NAS or an FA to
always target the same home AAA server in case there is more then one?
Furthermore, could you please tell me why this is really needed and if so, be a
little bit more specific how this should be done. I'm under the assumption that if
you have more than one AAA server in the same domain, you would have access to a
shared database, thus a re-authentication arriving at a different home AAA server
can be handled. Correct? Or is there any reason to argue otherwise?


>
>
> This means that the Resource-Owner-NAI is gone.
>
> This seems to work for reverse re-auth *and* termination messages.
>
> Comments?
>
> PatC






From owner-aaa-bof@merit.edu  Tue Jan 23 14:58:18 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23055
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 14:58:18 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 58DFD5DF3C; Tue, 23 Jan 2001 14:55:58 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 391225DE91; Tue, 23 Jan 2001 14:55:58 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 508F45DF32
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 14:55:53 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01889;
	Tue, 23 Jan 2001 11:55:45 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA11572;
	Tue, 23 Jan 2001 11:55:44 -0800 (PST)
Received: from cinnamon (cinnamon [129.146.122.100])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id LAA01693;
	Tue, 23 Jan 2001 11:55:42 -0800 (PST)
Date: Tue, 23 Jan 2001 11:54:51 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section  3.0
To: Tony Johansson <tony.johansson@ericsson.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>, Martin.Julien@ece.ericsson.se
In-Reply-To: "Your message with ID" <3A6DE01C.A7794FB5@ericsson.com>
Message-ID: <Roam.SIMC.2.0.6.980279691.14073.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> > sigh.
> 
> Well, first of all the Destination-NAI AVP was never intended to be used as
> described above, right?!. The Host-Name contains the originating host (i.e.
> the NAS or the FA) and the Host-Name AVP was copied into the Destination-NAI
> AVP for the return trip. The Destination-NAI AVP was then used to route the
> reply message back to the originating host. Correct ?

correct, it was used for inter-domain routing.

> 
> >
> >
> > Well I guess in my haste to remove support for different reverse path routing,
> > I removed an AVP that had additional uses.
> 
> What additional uses do you recall ?

see below.

> 
> > So, it looks like Destination-NAI
> > needs to be put back in, but with a much more limited set of functionality. It
> > will now ONLY be used to identify the host within the domain. The
> > Routing-Realm AVP is still used to identify the Domain, and once a server
> > identifies that the message made it to the destination realm, the
> > Destination-NAI is used to route to a specific host.
> 
> I'm not sure that I understand why we need this. Is it to allow a NAS or an
> FA to always target the same home AAA server in case there is more then one?
> Furthermore, could you please tell me why this is really needed and if so,
> be a little bit more specific how this should be done. I'm under the
> assumption that if you have more than one AAA server in the same domain, you
> would have access to a shared database, thus a re-authentication arriving at
> a different home AAA server can be handled. Correct? Or is there any reason
> to argue otherwise?

There are two uses that I can think of, both of which involve home server
initiated messages: - The home server wishes to send an STI to the NAS, to
force the session to be disconnected, and - The home server wishes to send a
re-auth request to the NAS.

Is this clearer?

PatC




From owner-aaa-bof@merit.edu  Tue Jan 23 15:03:50 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23164
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 15:03:49 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 1D3A15DED4; Tue, 23 Jan 2001 15:01:15 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 0C5835DEB8; Tue, 23 Jan 2001 15:01:15 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id BE0225DEB0
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 15:01:13 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14473;
	Tue, 23 Jan 2001 12:01:10 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA13542;
	Tue, 23 Jan 2001 12:01:09 -0800 (PST)
Received: from cinnamon (cinnamon [129.146.122.100])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA01774;
	Tue, 23 Jan 2001 12:01:07 -0800 (PST)
Date: Tue, 23 Jan 2001 12:00:16 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section  3.0
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: Tony Johansson <tony.johansson@ericsson.com>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>, Martin.Julien@ece.ericsson.se
In-Reply-To: "Your message with ID" <Roam.SIMC.2.0.6.980279691.14073.pcalhoun@nasnfs>
Message-ID: <Roam.SIMC.2.0.6.980280016.28245.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Re-reading this, it isn't that clear that I fully communicated the use of the
proposed new AVP. See more below. > 
> There are two uses that I can think of, both of which involve home server
> initiated messages: - The home server wishes to send an STI to the NAS, to
> force the session to be disconnected, and - The home server wishes to send a
> re-auth request to the NAS.
> 
The existing proxying techniques are still used, and we are not proposing
changing these. However, some AVP must be set to identify the actual NAS (or
server) within the domain. This new AVP would ONLY be used to identify a NAS
(or server) within a domain.

PatC




From owner-aaa-bof@merit.edu  Tue Jan 23 16:06:10 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24531
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 16:06:09 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 7520B5DD99; Tue, 23 Jan 2001 16:05:50 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 620905DDFE; Tue, 23 Jan 2001 16:05:50 -0500 (EST)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by segue.merit.edu (Postfix) with ESMTP id D5A295DD99
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 16:05:48 -0500 (EST)
Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f0NL5lK19214;
	Tue, 23 Jan 2001 15:05:47 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id f0NL27r11951;
	Tue, 23 Jan 2001 15:02:07 -0600 (CST)
Received: from qpop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA23722; Tue, 23 Jan 2001 15:05:44 -0600 (CST)
Received: from ericsson.com (busam57.berkeley.us.am.ericsson.se [138.85.159.207])
	by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA13533;
	Tue, 23 Jan 2001 15:05:41 -0600 (CST)
Message-ID: <3A6DF243.9D280B44@ericsson.com>
Date: Tue, 23 Jan 2001 13:06:12 -0800
From: Tony Johansson <tony.johansson@ericsson.com>
Organization: Ericsson Inc
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>, Martin.Julien@ece.ericsson.se
Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section  
 3.0
References: <Roam.SIMC.2.0.6.980280016.28245.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pat,

True, for the cases of home server initiated messages, like STI and re-auth
request to the NAS, we do need some thing to route the message to the right NAS or
FA and the AVP for that is the Resource-Owner-NAI AVP. Correct? If the idea here
is only to change the name from Resource-Owner-NAI AVP to Destination-NAI AVP, it
is fine with me.

Furthermore, just as clarification, if the case is to change the
Resource-Owner-NAI AVP to the Destination-NAI AVP it should stated in the text
that the Destination-NAI AVP should ONLY be used for messages originated from the
AAA server. Correct?


BR,

/Tony


Pat Calhoun wrote:

> Re-reading this, it isn't that clear that I fully communicated the use of the
> proposed new AVP. See more below. >
> > There are two uses that I can think of, both of which involve home server
> > initiated messages: - The home server wishes to send an STI to the NAS, to
> > force the session to be disconnected, and - The home server wishes to send a
> > re-auth request to the NAS.
> >
> The existing proxying techniques are still used, and we are not proposing
> changing these. However, some AVP must be set to identify the actual NAS (or
> server) within the domain. This new AVP would ONLY be used to identify a NAS
> (or server) within a domain.
>
> PatC




From owner-aaa-bof@merit.edu  Tue Jan 23 16:11:31 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24680
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 16:11:31 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id BE58D5DE54; Tue, 23 Jan 2001 16:11:11 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id ADC1B5DE4A; Tue, 23 Jan 2001 16:11:11 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 44DA85DDFE
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 16:11:10 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA01991;
	Tue, 23 Jan 2001 13:11:06 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA23434;
	Tue, 23 Jan 2001 13:11:04 -0800 (PST)
Received: from cinnamon (cinnamon [129.146.122.100])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA02809;
	Tue, 23 Jan 2001 13:11:02 -0800 (PST)
Date: Tue, 23 Jan 2001 13:10:10 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section   3.0
To: Tony Johansson <tony.johansson@ericsson.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>, Martin.Julien@ece.ericsson.se
In-Reply-To: "Your message with ID" <3A6DF243.9D280B44@ericsson.com>
Message-ID: <Roam.SIMC.2.0.6.980284210.27980.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Hi Pat,
> 
> True, for the cases of home server initiated messages, like STI and re-auth
> request to the NAS, we do need some thing to route the message to the right
> NAS or FA and the AVP for that is the Resource-Owner-NAI AVP. Correct? If
> the idea here is only to change the name from Resource-Owner-NAI AVP to
> Destination-NAI AVP, it is fine with me.

yes, the issue is that the REsource-Owner-NAI is tied to ST* messages. We need
something that can be used with re-auth as well. Destination-NAI is one name
we could use.

> 
> Furthermore, just as clarification, if the case is to change the
> Resource-Owner-NAI AVP to the Destination-NAI AVP it should stated in the
> text that the Destination-NAI AVP should ONLY be used for messages
> originated from the AAA server. Correct?

Correct. If that is the case, perhaps NAS-NAI is more appropriate.

PatC




From owner-aaa-bof@merit.edu  Tue Jan 23 17:59:16 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25949
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 17:59:16 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 8F5DD5DDE0; Tue, 23 Jan 2001 17:58:57 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 7C61B5DE4A; Tue, 23 Jan 2001 17:58:57 -0500 (EST)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by segue.merit.edu (Postfix) with ESMTP id 27BFD5DDE0
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 17:58:56 -0500 (EST)
Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f0NMwtK01986;
	Tue, 23 Jan 2001 16:58:55 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id f0NMtFr10131;
	Tue, 23 Jan 2001 16:55:15 -0600 (CST)
Received: from qpop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA29377; Tue, 23 Jan 2001 16:58:53 -0600 (CST)
Received: from ericsson.com (busam57.berkeley.us.am.ericsson.se [138.85.159.207])
	by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA15741;
	Tue, 23 Jan 2001 16:58:50 -0600 (CST)
Message-ID: <3A6E0CC6.402CDC47@ericsson.com>
Date: Tue, 23 Jan 2001 14:59:18 -0800
From: Tony Johansson <tony.johansson@ericsson.com>
Organization: Ericsson Inc
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>, Martin.Julien@ece.ericsson.se
Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Section   
 3.0
References: <Roam.SIMC.2.0.6.980284210.27980.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I would prefer Destination-NAI AVP or something similar, thus a more general name,
which works well for both a NAS (with re-auth and ST* messages) or an FA (with ST*
messages).

BR,

/Tony

Pat Calhoun wrote:

> > Hi Pat,
> >
> > True, for the cases of home server initiated messages, like STI and re-auth
> > request to the NAS, we do need some thing to route the message to the right
> > NAS or FA and the AVP for that is the Resource-Owner-NAI AVP. Correct? If
> > the idea here is only to change the name from Resource-Owner-NAI AVP to
> > Destination-NAI AVP, it is fine with me.
>
> yes, the issue is that the REsource-Owner-NAI is tied to ST* messages. We need
> something that can be used with re-auth as well. Destination-NAI is one name
> we could use.
>
> >
> > Furthermore, just as clarification, if the case is to change the
> > Resource-Owner-NAI AVP to the Destination-NAI AVP it should stated in the
> > text that the Destination-NAI AVP should ONLY be used for messages
> > originated from the AAA server. Correct?
>
> Correct. If that is the case, perhaps NAS-NAI is more appropriate.
>
> PatC

--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_

  Tony Johansson
  Mobile Networking Research
  Ericsson Inc.    mobile: +1 510 305 6108
  2100 Shattuck Avenue
  Berkeley, CA, 94704
                         mailto:tony.johansson@ericsson.com
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_





From owner-aaa-bof@merit.edu  Tue Jan 23 19:22:25 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26964
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 19:22:25 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id BAA2C5DE5B; Tue, 23 Jan 2001 19:22:05 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A9E365DE4A; Tue, 23 Jan 2001 19:22:05 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 89D865DE2B
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 19:22:04 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA11525
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 16:21:59 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA16703
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 16:21:58 -0800 (PST)
Received: from cinnamon (cinnamon [129.146.122.100])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA06541
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 16:21:57 -0800 (PST)
Date: Tue, 23 Jan 2001 16:21:05 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: [AAA-WG]: DIAMETER Sessions State Machine
To: aaa-wg@merit.edu
Message-ID: <Roam.SIMC.2.0.6.980295665.17067.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

All,

At Dave Spence's request, I've put together a state machine that would explain
how sessions are created, and terminated, and how the various ST* messages are
used. I know that Barney typically doesn't like server internals to be
discussed, but Dave thought it would be necessary in the spec.

Here is what I've come up with, and I would solicit comments on whether it is
considered useful in the base protocol spec (again, this is not new
functionality, but rather clarification to ease interoperability).

3.1  State Machine

   This section contains a finite state machine, representing the life
   cycle of DIAMETER sessions, and MUST be observed by all DIAMETER
   implementations.  The term Service-Specific below refers to a message
   defined in a DIAMETER extension (e.g. Mobile IP, NASREQ).

      State     Event                          Action     New State
      -----     -----                          ------     ---------
      Idle      Client or Device Requests      send serv. Pending
                access                         specific
                                               auth req

      Idle      Service-Specific authorization send serv. Open
                request received, and          specific
                successfully processed         response

      Pending   Successful Service-Specific    Grant      Open
                Authorization response         Access
                received

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

      Open      Successful Service-Specific    Extend     Open
                Authorization response         Access
                received

      Open      Failed Service-Specific        Discon.    Cleanup
                Authorization response         user/device
                received.

      Open      Session-Timeout Expires on     send STR   Discon
                NAS

      Open      Session-Timeout Expires on     send STI   Discon
                home AAA server

      Discon    STI Received                   ignore     Discon

      Discon    STR Received                   Discon.    Cleanup
                                               user/device

      Discon    STA Received                   Discon.    Cleanup
                                               user/device

   When the Cleanup action is invoked, the DIAMETER node SHOULD attempt
   to release all resources for the particular session.




From owner-aaa-bof@merit.edu  Tue Jan 23 19:51:38 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27239
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 19:51:38 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 581EB5DE5E; Tue, 23 Jan 2001 19:51:09 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 463165DE4A; Tue, 23 Jan 2001 19:51:09 -0500 (EST)
Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44])
	by segue.merit.edu (Postfix) with ESMTP id 9C6795DE2B
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 19:51:07 -0500 (EST)
Received: (from barney@localhost)
	by mx.databus.com (8.11.1/8.11.1) id f0O0p5I23140;
	Tue, 23 Jan 2001 19:51:05 -0500 (EST)
	(envelope-from barney)
Date: Tue, 23 Jan 2001 19:51:05 -0500
From: Barney Wolff <barney@databus.com>
To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Cc: aaa-wg@merit.edu
Subject: Re: [AAA-WG]: DIAMETER Sessions State Machine
Message-ID: <20010123195104.A23027@mx.databus.com>
References: <Roam.SIMC.2.0.6.980295665.17067.pcalhoun@nasnfs>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Roam.SIMC.2.0.6.980295665.17067.pcalhoun@nasnfs>; from Pat.Calhoun@Eng.Sun.COM on Tue, Jan 23, 2001 at 04:21:05PM -0800
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

A few comments.

1.  I have no problem with the state machine as it
describes required externally-visible actions.  I'd put
releasing resources as "may wish to" (note lower case)
rather than SHOULD, and Cleanup as an action, not a state,
but I won't be fanatic about it.

2.  A state machine description that does not include all
combinations of events x states is incomplete.  For example,
it is valid (for the NAS) to receive STI in Open, and action
is required.  Some other combinations are not valid, but
something needs to be specified, especially if a state
transition should result.

3.  If I'm not mistaken you've overloaded "auth" as both
authentication and authorization.  I sure wish we had
terms that could not be so confounded.

4.  Role-independent description makes me a little nervous.
A NAS should certainly treat an incoming access-request
quite differently than a server, and having one FSM
description buries this fundamental difference in the
notion of "successfully processed".

Barney

On Tue, Jan 23, 2001 at 04:21:05PM -0800, Pat Calhoun wrote:
> All,
> 
> At Dave Spence's request, I've put together a state machine that would explain
> how sessions are created, and terminated, and how the various ST* messages are
> used. I know that Barney typically doesn't like server internals to be
> discussed, but Dave thought it would be necessary in the spec.
> 
> Here is what I've come up with, and I would solicit comments on whether it is
> considered useful in the base protocol spec (again, this is not new
> functionality, but rather clarification to ease interoperability).
> 
> 3.1  State Machine
> 
>    This section contains a finite state machine, representing the life
>    cycle of DIAMETER sessions, and MUST be observed by all DIAMETER
>    implementations.  The term Service-Specific below refers to a message
>    defined in a DIAMETER extension (e.g. Mobile IP, NASREQ).
> 
>       State     Event                          Action     New State
>       -----     -----                          ------     ---------
>       Idle      Client or Device Requests      send serv. Pending
>                 access                         specific
>                                                auth req
> 
>       Idle      Service-Specific authorization send serv. Open
>                 request received, and          specific
>                 successfully processed         response
> 
>       Pending   Successful Service-Specific    Grant      Open
>                 Authorization response         Access
>                 received
> 
>       Open      Authorization-Lifetime expires send serv. Open
>                                                specific
>                                                auth req
> 
>       Open      Successful Service-Specific    Extend     Open
>                 Authorization response         Access
>                 received
> 
>       Open      Failed Service-Specific        Discon.    Cleanup
>                 Authorization response         user/device
>                 received.
> 
>       Open      Session-Timeout Expires on     send STR   Discon
>                 NAS
> 
>       Open      Session-Timeout Expires on     send STI   Discon
>                 home AAA server
> 
>       Discon    STI Received                   ignore     Discon
> 
>       Discon    STR Received                   Discon.    Cleanup
>                                                user/device
> 
>       Discon    STA Received                   Discon.    Cleanup
>                                                user/device
> 
>    When the Cleanup action is invoked, the DIAMETER node SHOULD attempt
>    to release all resources for the particular session.
> 
> 



From owner-aaa-bof@merit.edu  Tue Jan 23 20:04:12 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27421
	for <aaa-archive@odin.ietf.org>; Tue, 23 Jan 2001 20:04:11 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 669F65DE2B; Tue, 23 Jan 2001 20:02:32 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 503715DE6D; Tue, 23 Jan 2001 20:02:32 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id DFC685DE2B
	for <aaa-wg@merit.edu>; Tue, 23 Jan 2001 20:02:30 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA22567;
	Tue, 23 Jan 2001 17:02:26 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA24137;
	Tue, 23 Jan 2001 16:56:35 -0800 (PST)
Received: from cinnamon (cinnamon [129.146.122.100])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA07435;
	Tue, 23 Jan 2001 16:56:29 -0800 (PST)
Date: Tue, 23 Jan 2001 16:55:37 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [AAA-WG]: DIAMETER Sessions State Machine
To: Barney Wolff <barney@databus.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>, aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <20010123195104.A23027@mx.databus.com>
Message-ID: <Roam.SIMC.2.0.6.980297737.15835.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> A few comments.
> 
> 1.  I have no problem with the state machine as it
> describes required externally-visible actions.  I'd put
> releasing resources as "may wish to" (note lower case)
> rather than SHOULD, and Cleanup as an action, not a state,
> but I won't be fanatic about it.

check. SHOULD->MAY, and cleanup as an action.

> 
> 2.  A state machine description that does not include all
> combinations of events x states is incomplete.  For example,
> it is valid (for the NAS) to receive STI in Open, and action
> is required.  Some other combinations are not valid, but
> something needs to be specified, especially if a state
> transition should result.

OOps, missed the STI :(

I do not see any other valid combinations, so perhaps a statement that
anything outside the state machine is an error (as opposed to listing every
possible error condition)?

> 
> 3.  If I'm not mistaken you've overloaded "auth" as both
> authentication and authorization.  I sure wish we had
> terms that could not be so confounded.

Not really. I see authorization as granting access. Authentication is a means
towards authorization (in some cases).

> 
> 4.  Role-independent description makes me a little nervous.
> A NAS should certainly treat an incoming access-request
> quite differently than a server, and having one FSM
> description buries this fundamental difference in the
> notion of "successfully processed".

I hated this one as well, but it was the ONLY line that was NAS specific. I
will look at changing it so it is cleaner, but I had to have two (nearly
identical) state machines.

Thanks,

PatC
> 
> Barney
> 
> On Tue, Jan 23, 2001 at 04:21:05PM -0800, Pat Calhoun wrote:
> > All,
> > 
> > At Dave Spence's request, I've put together a state machine that would explain
> > how sessions are created, and terminated, and how the various ST* messages are
> > used. I know that Barney typically doesn't like server internals to be
> > discussed, but Dave thought it would be necessary in the spec.
> > 
> > Here is what I've come up with, and I would solicit comments on whether it is
> > considered useful in the base protocol spec (again, this is not new
> > functionality, but rather clarification to ease interoperability).
> > 
> > 3.1  State Machine
> > 
> >    This section contains a finite state machine, representing the life
> >    cycle of DIAMETER sessions, and MUST be observed by all DIAMETER
> >    implementations.  The term Service-Specific below refers to a message
> >    defined in a DIAMETER extension (e.g. Mobile IP, NASREQ).
> > 
> >       State     Event                          Action     New State
> >       -----     -----                          ------     ---------
> >       Idle      Client or Device Requests      send serv. Pending
> >                 access                         specific
> >                                                auth req
> > 
> >       Idle      Service-Specific authorization send serv. Open
> >                 request received, and          specific
> >                 successfully processed         response
> > 
> >       Pending   Successful Service-Specific    Grant      Open
> >                 Authorization response         Access
> >                 received
> > 
> >       Open      Authorization-Lifetime expires send serv. Open
> >                                                specific
> >                                                auth req
> > 
> >       Open      Successful Service-Specific    Extend     Open
> >                 Authorization response         Access
> >                 received
> > 
> >       Open      Failed Service-Specific        Discon.    Cleanup
> >                 Authorization response         user/device
> >                 received.
> > 
> >       Open      Session-Timeout Expires on     send STR   Discon
> >                 NAS
> > 
> >       Open      Session-Timeout Expires on     send STI   Discon
> >                 home AAA server
> > 
> >       Discon    STI Received                   ignore     Discon
> > 
> >       Discon    STR Received                   Discon.    Cleanup
> >                                                user/device
> > 
> >       Discon    STA Received                   Discon.    Cleanup
> >                                                user/device
> > 
> >    When the Cleanup action is invoked, the DIAMETER node SHOULD attempt
> >    to release all resources for the particular session.
> > 
> > 





From owner-aaa-bof@merit.edu  Wed Jan 24 09:04:39 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20825
	for <aaa-archive@odin.ietf.org>; Wed, 24 Jan 2001 09:04:39 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 61FC15DE47; Wed, 24 Jan 2001 09:03:26 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 49F895DEA0; Wed, 24 Jan 2001 09:03:26 -0500 (EST)
Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16])
	by segue.merit.edu (Postfix) with ESMTP id 9A8665DE47
	for <aaa-wg@segue.merit.edu>; Wed, 24 Jan 2001 09:03:22 -0500 (EST)
Received: from oleane (dyn-1-1-051.Vin.dialup.oleane.fr [195.25.4.51]) by smtp1.cluster.oleane.net with SMTP id f0OE3H625239 for <aaa-wg@segue.merit.edu>; Wed, 24 Jan 2001 15:03:18 +0100 (CET)
Message-ID: <005301c0860e$8bbda6a0$8001a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <aaa-wg@merit.edu>
Subject: [AAA-WG]: IPCN '01 conference 
Date: Wed, 24 Jan 2001 15:04:18 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0050_01C08616.ECF29FE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0050_01C08616.ECF29FE0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

The request for proposals dead line for the IPCN '01 conference =
(IP-based Cellular Networks) has been extended to February 15th.
Please get more details at:
http://www.upperside.fr/baipcn2001.htm


------=_NextPart_000_0050_01C08616.ECF29FE0
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT color=3D#000000 size=3D2>The request for proposals dead line =
for the IPCN=20
'01 conference (<STRONG>IP-based Cellular Networks</STRONG>) has been =
extended=20
to February 15th.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Please get more details =
at:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><A=20
href=3D"http://www.upperside.fr/baipcn2001.htm">http://www.upperside.fr/b=
aipcn2001.htm</A></FONT></DIV>
<DIV>&nbsp;</DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_0050_01C08616.ECF29FE0--




From owner-aaa-bof@merit.edu  Wed Jan 24 09:07:15 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20895
	for <aaa-archive@odin.ietf.org>; Wed, 24 Jan 2001 09:07:15 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 32C405DDD3; Wed, 24 Jan 2001 09:06:57 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 20EF15DDD2; Wed, 24 Jan 2001 09:06:57 -0500 (EST)
Received: from roam.psg.com (dhcp70.ripemtg.ripe.net [193.0.4.70])
	by segue.merit.edu (Postfix) with ESMTP id 902945DDD3
	for <aaa-wg@merit.edu>; Wed, 24 Jan 2001 09:06:55 -0500 (EST)
Received: from randy by roam.psg.com with local (Exim 3.12 #1)
	id 14LQZS-0002kI-00; Wed, 24 Jan 2001 15:06:46 +0100
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Peter Lewis" <peter.lewis@upperside.fr>
Cc: <aaa-wg@merit.edu>, IETF Secretariat <ietf-secretariat@ietf.org>
Subject: Re: [AAA-WG]: IPCN '01 conference 
References: <005301c0860e$8bbda6a0$8001a8c0@oleane.com>
Message-Id: <E14LQZS-0002kI-00@roam.psg.com>
Date: Wed, 24 Jan 2001 15:06:46 +0100
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

> The request for proposals dead line for the IPCN '01 conference (IP-based Cellular Networks) has been extended to February 15th.
> Please get more details at:
> http://www.upperside.fr/baipcn2001.htm

will the list manager please block future postings from this low-life
slimeball spammer?  thank you.

randy, ad hat on



From owner-aaa-bof@merit.edu  Wed Jan 24 09:22:39 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21423
	for <aaa-archive@odin.ietf.org>; Wed, 24 Jan 2001 09:22:39 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 800505DDD2; Wed, 24 Jan 2001 09:22:16 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 682FA5DDDA; Wed, 24 Jan 2001 09:22:16 -0500 (EST)
Received: from localhost.ipunplugged.com (unknown [195.42.212.161])
	by segue.merit.edu (Postfix) with ESMTP id A72855DDD2
	for <aaa-wg@merit.edu>; Wed, 24 Jan 2001 09:22:14 -0500 (EST)
Received: from fredrikj (c38.local.ipunplugged.com [192.168.4.237])
	by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id PAA05753;
	Wed, 24 Jan 2001 15:22:58 +0100
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Pat Calhoun" <Pat.Calhoun@Eng.Sun.COM>
Cc: "AAA Listan" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Re: Comments on draft-calhoun-diameter-18.txt
Date: Wed, 24 Jan 2001 15:24:35 +0100
Message-ID: <MJEMJBGGCLLDLFFAHLJKIEHECFAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Roam.SIMC.2.0.6.979950087.30340.pcalhoun@nasnfs>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pat,

One down one to go :-)
Still a typo in section 8.2. The command code value for DRI should be 257.

/Fredrik


>> Hi
>> 
>> Found a type in section 8.2. The Command Codes that are specified within
>> this specification should be 257, 259, 274-276
>> Compare section 8.2 with 2.1
>
>check. 
>
>Thanks,
>
>PatC
>



From owner-aaa-bof@merit.edu  Wed Jan 24 10:48:38 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23922
	for <aaa-archive@odin.ietf.org>; Wed, 24 Jan 2001 10:48:38 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 489125DEB0; Wed, 24 Jan 2001 10:46:10 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 2BC825DED6; Wed, 24 Jan 2001 10:46:10 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id BDC745DEB0
	for <aaa-wg@merit.edu>; Wed, 24 Jan 2001 10:46:08 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28515
	for <aaa-wg@merit.edu>; Wed, 24 Jan 2001 07:46:08 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA12705
	for <aaa-wg@merit.edu>; Wed, 24 Jan 2001 07:46:04 -0800 (PST)
Received: from cinnamon (cinnamon [129.146.122.100])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA21150
	for <aaa-wg@merit.edu>; Wed, 24 Jan 2001 07:46:06 -0800 (PST)
Date: Wed, 24 Jan 2001 07:45:14 -0800 (PST)
From: Pat Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Pat Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: [AAA-WG]: New proposed text for Destination-NAI
To: aaa-wg@merit.edu
Message-ID: <Roam.SIMC.2.0.6.980351114.1231.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

All,

As discussed in the past couple of days, some mechanism is required for STI
and other server initiated re-auth messages to find its way to the proper NAS.
The following text is what I would propose in the next I-D:

Comments (please!),

PatC
----
6.8  Finding a Target NAS within a Domain

   The DIAMETER protocol supports unsolicited server initiated messages.
   However, when such messages are transmitted, they have a specific
   target Network Access Server (NAS) in mind. Unsolicited server
   initiated messages are unique in that they contain the Destination-
   NAI AVP. Routing of such messages follow the same set of guidelines
   described in section 6.0, with one exception. When a proxy server has
   determined that a message, which includes the Destination-NAI AVP,
   has reached its target realm, the Destination-NAI AVP is used to
   identify the actual NAS the message should be forwarded to.


6.8.1  Destination-NAI AVP

   The Destination-NAI AVP (AVP Code 293) [1] is of type OctetString,
   and contains the NAI [8] of the intended recipient of the message.
   This AVP MUST be present in all unsolicited server initiated
   messages.






From owner-aaa-bof@merit.edu  Thu Jan 25 06:04:43 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23204
	for <aaa-archive@odin.ietf.org>; Thu, 25 Jan 2001 06:04:42 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id C8A7E5DD8E; Thu, 25 Jan 2001 06:02:44 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A79715DE02; Thu, 25 Jan 2001 06:02:44 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by segue.merit.edu (Postfix) with ESMTP id 48DB25DD8E
	for <aaa-wg@merit.edu>; Thu, 25 Jan 2001 06:02:42 -0500 (EST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f0PB2eC01852
	for <aaa-wg@merit.edu>; Thu, 25 Jan 2001 12:02:41 +0100 (MET)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Thu Jan 25 12:02:46 2001 +0100
Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58)
	id <Z2G9K1Q9>; Thu, 25 Jan 2001 12:02:39 +0100
Message-ID: <577066326047D41180AC00508B955DDA01D7FE71@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        "'DSpence@Interlinknetworks.com'" <DSpence@Interlinknetworks.com>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Cc: "'barney@databus.com'" <barney@databus.com>
Subject: RE: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec
	 tion 3.0
Date: Thu, 25 Jan 2001 12:02:30 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA23204

Hi again,

Sorry, I could not be part of yesterday´s discussion, but I'm very happy with the outcome. See enclosed comments.

Martin

> -----Original Message-----
> From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com]
> Sent: Tuesday, January 23, 2001 6:55 PM
> 
> > 
> > I also have a comment on the idea of including an 
> Extension-ID AVP in STRs
> > and STIs.  I can understand the desire to be able to 
> terminate subsessions
> > of a complex session, but DIAMETER doesn't really support 
> subsessions.  I
> > can also understand the need to free some resources within 
> a session without
> > terminating the entire session.  But to do that, you need 
> real resource
> > management, and DIAMETER doesn't do that either.  I don't 
> think trying to do
> > pseudo-resouce management through the use of the 
> Extension-ID AVP is a
> > particularly good idea.  The Extension-ID does not really indicate
> > resources, nor does it precisely indicate applications 
> either.  Instead it
> > simply indicates which subsets of DIAMETER are being used 
> in the protocol
> > exchange.  So what would it mean if a server receives an 
> STR (or STI)
> > specifying some Session-ID and the NASREQ Extension-ID, but not the
> > Strong-Crypto Extension-ID which was also used in 
> establishing the session? 
> > Or if a server receives an STR specifying the Accounting 
> Extension-ID but
> > not the NASREQ Extension-ID (although maybe we've decided to include
> > accounting in the service extensions)?
> 
> Good argument against extension ID in STRs.
> 
> > 
> > Anyway, I think if we want to do resource management, then 
> we should figure
> > out how to do resource management and not try to slap 
> together a quick fix
> > that uses the wrong data element for the wrong purpose.  
> 
> ok, that works for me as well, since it is the easiest (both 
> in terms of
> documentation as well as implementation).
> 
> PatC
> 
> 

I think you brought a very interesting point and I totally agree with you. IMHO, we should probably think of a well-defined way of doing resource mgmt before we go further on this discussion. So we should use the STR/STA and STI messages to simply release the user session, which automatically means all resources owned by the session, right? That's simple enough for now. I will try to see what we should/could do for resource mgmt in another thread of this ML.

Martin



From owner-aaa-bof@merit.edu  Thu Jan 25 07:33:27 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24279
	for <aaa-archive@odin.ietf.org>; Thu, 25 Jan 2001 07:33:26 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id A39495DE10; Thu, 25 Jan 2001 07:30:20 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id CD1205DE1B; Thu, 25 Jan 2001 07:30:19 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by segue.merit.edu (Postfix) with ESMTP id 6A2A85DE10
	for <aaa-wg@merit.edu>; Thu, 25 Jan 2001 07:30:14 -0500 (EST)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f0PCUDC08399
	for <aaa-wg@merit.edu>; Thu, 25 Jan 2001 13:30:13 +0100 (MET)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Thu Jan 25 13:30:19 2001 +0100
Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58)
	id <Z2G9K25B>; Thu, 25 Jan 2001 13:30:12 +0100
Message-ID: <577066326047D41180AC00508B955DDA01D7FE72@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Tony Johansson'" <tony.johansson@ericsson.com>,
        Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec
	tion 3.0
Date: Thu, 25 Jan 2001 13:29:55 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Hi Tony and Pat,

I would like to know why we can not use a more simple routing scheme based on Destination-NAI AVP (let's call it like that for now), to route the packet directly to the destination server, which could either be a NAS or an AAAH? The format of the Destination-NAI AVP could be something like "server1@realm.com", which could be used by the proxies to route messages to their final destination domain, and then to a particular server within the domain. So the order of priority for routing would be something like: (1) Destination-NAI, (2) Routing-Realm. I assumed that the originating servers should always use a Routing-Realm AVP (a default one in the case no User-Name AVP is available) or a Destination-NAI AVP (possibly extracted from the User-Name AVP like "@realm.com" with no server name, only domain) when sending messages. I assumed that the Routing-Realm AVP was only used when we did not really know where the message should go because the User-Name AVP was not yet available? I !
think it would simplify the routing scheme. Would that make any sense? The problem with the Routing-Realm AVP being used as the highest priority routing scheme is that I don't really know what will happen on the different proxies, since they might change it.

Even tough we can assume that if more than one server is part of a AAAH domain and they would all share the same DB for user info, I don't know if it would be desirable to also put user session information in the DB in the case that messages from the access device (NAS) would need to send a STR to its very particular AAAH server. Then, the message could get routed to another server within the domain, that does not have access to the memory resident user session info. It remains the responsibility of the domain to use the "server1" part of the "server1@realm.com" address as it wishes, which should not be a problem if user sessions are shared among AAAH servers for load balancing and 100% availability. This solution would be more generic, which I think you like.  

Basically, I liked to idea behind the Resource-Owner AVP routing concept very much and think it is good, but I thought it also needed to be extended to handle both-ways messaging.

BR,
Martin

> -----Original Message-----
> From: Tony Johansson [mailto:tony.johansson@ericsson.com]
> Sent: Tuesday, January 23, 2001 11:59 PM
> To: Pat Calhoun
> Cc: 'aaa-wg@merit.edu'; Martin.Julien@ece.ericsson.se
> Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments
> Section 3.0
> 
> 
> I would prefer Destination-NAI AVP or something similar, thus 
> a more general name,
> which works well for both a NAS (with re-auth and ST* 
> messages) or an FA (with ST*
> messages).
> 
> BR,
> 
> /Tony
> 
> Pat Calhoun wrote:
> 
> > > Hi Pat,
> > >
> > > True, for the cases of home server initiated messages, 
> like STI and re-auth
> > > request to the NAS, we do need some thing to route the 
> message to the right
> > > NAS or FA and the AVP for that is the Resource-Owner-NAI 
> AVP. Correct? If
> > > the idea here is only to change the name from 
> Resource-Owner-NAI AVP to
> > > Destination-NAI AVP, it is fine with me.
> >
> > yes, the issue is that the REsource-Owner-NAI is tied to 
> ST* messages. We need
> > something that can be used with re-auth as well. 
> Destination-NAI is one name
> > we could use.
> >
> > >
> > > Furthermore, just as clarification, if the case is to change the
> > > Resource-Owner-NAI AVP to the Destination-NAI AVP it 
> should stated in the
> > > text that the Destination-NAI AVP should ONLY be used for messages
> > > originated from the AAA server. Correct?
> >
> > Correct. If that is the case, perhaps NAS-NAI is more appropriate.
> >
> > PatC
> 
> --
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> _/_/_/_/_
> 
>   Tony Johansson
>   Mobile Networking Research
>   Ericsson Inc.    mobile: +1 510 305 6108
>   2100 Shattuck Avenue
>   Berkeley, CA, 94704
>                          mailto:tony.johansson@ericsson.com
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> _/_/_/_/_
> 
> 
> 



From owner-aaa-bof@merit.edu  Thu Jan 25 08:29:35 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25466
	for <aaa-archive@odin.ietf.org>; Thu, 25 Jan 2001 08:29:34 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id C80CA5DE1B; Thu, 25 Jan 2001 08:29:15 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id B70F05DDE1; Thu, 25 Jan 2001 08:29:15 -0500 (EST)
Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110])
	by segue.merit.edu (Postfix) with ESMTP id D5E8A5DDB0
	for <aaa-wg@merit.edu>; Thu, 25 Jan 2001 08:29:14 -0500 (EST)
Received: from Interlinknetworks.com (slip139-92-165-12.zwo.nl.ibm.net [139.92.165.12])
	by aaa.interlinknetworks.com (Postfix) with ESMTP
	id 1066B72; Thu, 25 Jan 2001 08:29:22 -0500 (EST)
Message-ID: <3A700AD3.52D4668D@Interlinknetworks.com>
Date: Thu, 25 Jan 2001 00:15:31 -0500
From: David Spence <DSpence@Interlinknetworks.com>
Organization: Interlink Networks, Inc.
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <pcalhoun@nasnfs.eng.sun.com>
Cc: aaa-wg@merit.edu
Subject: Re: [AAA-WG]: New proposed text for Destination-NAI
References: <Roam.SIMC.2.0.6.980351114.1231.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat Calhoun wrote:
> 
> All,
> 
> As discussed in the past couple of days, some mechanism is required for STI
> and other server initiated re-auth messages to find its way to the proper NAS.
> The following text is what I would propose in the next I-D:
> 
> Comments (please!),

Well, for starters, I would suggest replacing the terms "Network Access
Server (NAS)" and "NAS" where they appear with the term "DIAMETER client" as
defined in section 1.0.  This is, after all, the base protocol -- not the
NASREQ extension.

Next, I think it might help to say something about how an AAA server would
know what value to assign to the Destination-NAI AVP.  Presumably it should
be set to the value of the Host-Name AVP that appeared in the message from
the DIAMETER client that established the session.  Correct?

> 
> PatC
> ----
> 6.8  Finding a Target NAS within a Domain
> 
>    The DIAMETER protocol supports unsolicited server initiated messages.
>    However, when such messages are transmitted, they have a specific
>    target Network Access Server (NAS) in mind. Unsolicited server
>    initiated messages are unique in that they contain the Destination-
>    NAI AVP. Routing of such messages follow the same set of guidelines
>    described in section 6.0, with one exception. When a proxy server has
>    determined that a message, which includes the Destination-NAI AVP,
>    has reached its target realm, the Destination-NAI AVP is used to
>    identify the actual NAS the message should be forwarded to.
> 
> 6.8.1  Destination-NAI AVP
> 
>    The Destination-NAI AVP (AVP Code 293) [1] is of type OctetString,
>    and contains the NAI [8] of the intended recipient of the message.
>    This AVP MUST be present in all unsolicited server initiated
>    messages.

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




From owner-aaa-bof@merit.edu  Thu Jan 25 09:38:17 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27128
	for <aaa-archive@odin.ietf.org>; Thu, 25 Jan 2001 09:38:16 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 498B05DEE5; Thu, 25 Jan 2001 09:35:18 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 2EDD65DED2; Thu, 25 Jan 2001 09:35:18 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by segue.merit.edu (Postfix) with ESMTP id 0FCEC5DEEE
	for <aaa-wg@merit.edu>; Thu, 25 Jan 2001 09:35:14 -0500 (EST)
Received: from esealnt462.al.sw.ericsson.se (esealnt462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f0PEZCC15215
	for <aaa-wg@merit.edu>; Thu, 25 Jan 2001 15:35:12 +0100 (MET)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Jan 25 15:36:05 2001 +0100
Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58)
	id <Z2G9K3RF>; Thu, 25 Jan 2001 15:35:12 +0100
Message-ID: <577066326047D41180AC00508B955DDA01D7FE74@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Pat Calhoun'" <Pat.Calhoun@eng.sun.com>,
        David Spence <DSpence@Interlinknetworks.com>
Cc: Barney Wolff <barney@databus.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec
	 tion 3.0
Date: Thu, 25 Jan 2001 15:35:03 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Pat,

I like David's solution, since it seems to handle the case where the Session-Timeout is reached in the AAAH server, as well as the one where a particular policy in the AAAH server triggers a user session termination in the DIAMETER client and server. So, if I understand correctly, it seems that the sending of a STI by the AAAH server to a DIAMETER client (access device) could mean for the client that it could send any other types of DIAMETER message it wants to re-authorize the session or example, not only a STR, right? For example, if a policy in the AAAH triggers a STI, then the DIAMETER client could possibly send a STR to terminate officially the user session or send a re-authorization message to re-authorize the session until the next Session-Timeout. That would mean that the AAAH should expect something back after sending an STI, and should have a local timeout to handle a response from the DIAMETER client to terminate the user session or re-authorize it, for example. I!
 believe it is important for an AAA server to enforce policies, which, IMHO, is one of its major role, right? However, in the case where the DIAMETER client would not answer a STI, it is not clear to me yet what the AAAH should do exactly, especially with regards to accouting.

I think this idea is getting closer to the one I had when we discussed very briefly about the Session-Timeout AVP and the Authorization-Lifetime AVP. As discussed above, we could be using the Session-Timeout AVP for Re-Authentication/Re-Authorization instead of using a new Authorization-Lifetime AVP. However, maybe a small difference would be that the Authorization-Lifetime AVP would be used to trigger a Re-Authentication/Re-Authorization message from the DIAMETER client automatically as an optimization of the NASREQ extension, and the Session-Timeout AVP as a generic request to a DIAMETER client for information about what it wants to do now about the user session: terminate, re-authorize, or whatever would calm down the policies on the AAAH server.

BR,
Martin

> -----Original Message-----
> From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com]
> Sent: Tuesday, January 23, 2001 8:06 PM
> To: David Spence
> Cc: Barney Wolff; Pat Calhoun; Martin Julien (ECE); aaa-wg@merit.edu
> Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments
> Sec tion 3.0
> 
> 
> Good, so NAS MUST sent STR, home server MAY sent STI. race 
> conditions are
> handled by the NAS.
> 
> I'll have text written up later today to represent the 
> session state machine.
> 
> PatC
> > I'm o.k. with making it a MUST for the NAS and a MAY for 
> the home server. 
> > If the protocol is specified as I've proposed, it should 
> work either way.
> > 
> > Barney Wolff wrote:
> > > 
> > > I do not think the home server has to run a fine-grained timer,
> > > or any timer at all if it is not doing resource management.
> > > It can do fine-grained timing, if it's anal, but we MUST NOT :)
> > > make it a MUST.
> > > 
> > > Barney
> > > 
> > > On Tue, Jan 23, 2001 at 01:48:43PM -0500, David Spence wrote:
> > > > Actually, both the NAS and the home server have to run 
> a timer.  The home
> > > > server has to because he's the one who cares and he 
> wants to enforce his
> > > > policy.  The NAS has to because it is possible that the 
> home server will be
> > > > (temporarily) unreachable from the NAS at the time the 
> timeout is to occur.
> > > > The NAS has an interest in running the timer because if the home
> > > > organization will refuse to pay for a longer session 
> than the timeout
> > > > specifies, then the NAS wants to make sure it doesn't 
> provide a longer
> > > > session.
> > > >
> > > > This means that both parties will timeout approximately 
> simultaneously so a
> > > > termination collision is likely.  No problem.  The home 
> server is expecting
> > > > an STR in response to its STI, so if it receives the 
> STR generated by the
> > > > NAS' timeout, its happy.  The rule for the NAS is: 
> ignore an STI received in
> > > > STR-sent state.  So the NAS avoids sending a second 
> STR.  The home server
> > > > will send STA in response to STR and everyone is happy.
> > > >
> > > > Barney Wolff wrote:
> > > > >
> > > > > I'd say the NAS does it, as it should have the primary timing
> > > > > responsibility.  The server's timing is to avoid 
> getting stuck in
> > > > > a state, and can be quite coarse, or nonexistent if the server
> > > > > does not track session state.
> > > > >
> > > > > If the server had the primary
> > > > > timing responsibility, we wouldn't need the 
> session-timout avp at
> > > > > all, as it could just decide to terminate the session 
> when it wants
> > > > > to.  But I think that's a poor use of server cycles.
> > > > >
> > > > > Barney
> > > > >
> > > > > On Tue, Jan 23, 2001 at 08:39:50AM -0800, Pat Calhoun wrote:
> > > > > > Cool, I think we are nearly there. One more 
> question. Who initiates the STR?
> > > > > > Should it be the NAS, or the home server. We need 
> to provide some guidelines
> > > > > > to reduce the changes of such messages crossing 
> through the network.
> > > > > >
> > > > > > PatC
> > > > > >
> > > > > >
> > > >
> > > > --
> > > > David Spence                            email: 
> DSpence@Interlinknetworks.com
> > > > Interlink Networks, Inc.                phone: (734) 821-1203
> > > > 775 Technology Drive, Suite 200         fax:   (734) 821-1235
> > > > Ann Arbor, MI 48108
> > > > U.S.A.
> > 
> > -- 
> > David Spence                            email: 
> DSpence@Interlinknetworks.com
> > Interlink Networks, Inc.                phone: (734) 821-1203
> > 775 Technology Drive, Suite 200         fax:   (734) 821-1235
> > Ann Arbor, MI 48108           
> > U.S.A.
> 
> 



From owner-aaa-bof@merit.edu  Thu Jan 25 10:33:38 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00504
	for <aaa-archive@odin.ietf.org>; Thu, 25 Jan 2001 10:33:38 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 8302A5DEE7; Thu, 25 Jan 2001 10:31:08 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 6FAE85DEE6; Thu, 25 Jan 2001 10:31:08 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 1F3C05DED7
	for <aaa-wg@merit.edu>; Thu, 25 Jan 2001 10:31:07 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA03886;
	Thu, 25 Jan 2001 07:31:01 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03694;
	Thu, 25 Jan 2001 07:31:01 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA12616;
	Thu, 25 Jan 2001 07:30:55 -0800 (PST)
Date: Thu, 25 Jan 2001 07:30:55 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: RE: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments Sec tion 3.0
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Cc: "'Tony Johansson'" <tony.johansson@ericsson.com>,
        Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FE72@eestqnt104.es.eu.ericsson.se>
Message-ID: <Roam.SIMC.2.0.6.980436655.14551.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Martin,

Thanks for the comment.

I understand your concern, but from what I've heard on this list is that
people do not want to tie users to a particular AAA home server (anyone,
correct me if I am wrong). So, the Destination-NAI is (sort-of) the equivalent
of the User-Name AVP, but in the reverse direction. When a message is destined
for the home AAA server, the User-name is used to identify the home network.
For messages directed towards the NAS, the Destionation-NAI is used. [now that
I think of it, I am not sure this is clearly stated in the I-D]. The
destination-NAI is slightly different since it also encodes the host name to
which the message must be forwarded to.

Again, if people really want to tie users to a particular AAA server, then we
can relax the Destionation-NAI rules. Comments?

PatC
> Hi Tony and Pat,
> 
> I would like to know why we can not use a more simple routing scheme based
> on Destination-NAI AVP (let's call it like that for now), to route the
> packet directly to the destination server, which could either be a NAS or an
> AAAH? The format of the Destination-NAI AVP could be something like
> "server1@realm.com", which could be used by the proxies to route messages to
> their final destination domain, and then to a particular server within the
> domain. So the order of priority for routing would be something like: (1)
> Destination-NAI, (2) Routing-Realm. I assumed that the originating servers
> should always use a Routing-Realm AVP (a default one in the case no
> User-Name AVP is available) or a Destination-NAI AVP (possibly extracted
> from the User-Name AVP like "@realm.com" with no server name, only domain)
> when sending messages. I assumed that the Routing-Realm AVP was only used
> when we did not really know where the message should go because the
> User-Name AVP was not yet available? I ! think it would simplify the routing
> scheme. Would that make any sense? The problem with the Routing-Realm AVP
> being used as the highest priority routing scheme is that I don't really
> know what will happen on the different proxies, since they might change it.
> 
> Even tough we can assume that if more than one server is part of a AAAH
> domain and they would all share the same DB for user info, I don't know if
> it would be desirable to also put user session information in the DB in the
> case that messages from the access device (NAS) would need to send a STR to
> its very particular AAAH server. Then, the message could get routed to
> another server within the domain, that does not have access to the memory
> resident user session info. It remains the responsibility of the domain to
> use the "server1" part of the "server1@realm.com" address as it wishes,
> which should not be a problem if user sessions are shared among AAAH servers
> for load balancing and 100% availability. This solution would be more
> generic, which I think you like.  
> 
> Basically, I liked to idea behind the Resource-Owner AVP routing concept
> very much and think it is good, but I thought it also needed to be extended
> to handle both-ways messaging.
> 
> BR,
> Martin
> 
> > -----Original Message-----
> > From: Tony Johansson [mailto:tony.johansson@ericsson.com]
> > Sent: Tuesday, January 23, 2001 11:59 PM
> > To: Pat Calhoun
> > Cc: 'aaa-wg@merit.edu'; Martin.Julien@ece.ericsson.se
> > Subject: Re: [AAA-WG]: Re: DIAMETER Base Protocol (Alpha 1) - Comments
> > Section 3.0
> > 
> > 
> > I would prefer Destination-NAI AVP or something similar, thus 
> > a more general name,
> > which works well for both a NAS (with re-auth and ST* 
> > messages) or an FA (with ST*
> > messages).
> > 
> > BR,
> > 
> > /Tony
> > 
> > Pat Calhoun wrote:
> > 
> > > > Hi Pat,
> > > >
> > > > True, for the cases of home server initiated messages, 
> > like STI and re-auth
> > > > request to the NAS, we do need some thing to route the 
> > message to the right
> > > > NAS or FA and the AVP for that is the Resource-Owner-NAI 
> > AVP. Correct? If
> > > > the idea here is only to change the name from 
> > Resource-Owner-NAI AVP to
> > > > Destination-NAI AVP, it is fine with me.
> > >
> > > yes, the issue is that the REsource-Owner-NAI is tied to 
> > ST* messages. We need
> > > something that can be used with re-auth as well. 
> > Destination-NAI is one name
> > > we could use.
> > >
> > > >
> > > > Furthermore, just as clarification, if the case is to change the
> > > > Resource-Owner-NAI AVP to the Destination-NAI AVP it 
> > should stated in the
> > > > text that the Destination-NAI AVP should ONLY be used for messages
> > > > originated from the AAA server. Correct?
> > >
> > > Correct. If that is the case, perhaps NAS-NAI is more appropriate.
> > >
> > > PatC
> > 
> > --
> > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> > _/_/_/_/_
> > 
> >   Tony Johansson
> >   Mobile Networking Research
> >   Ericsson Inc.    mobile: +1 510 305 6108
> >   2100 Shattuck Avenue
> >   Berkeley, CA, 94704
> >                          mailto:tony.johansson@ericsson.com
> > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> > _/_/_/_/_
> > 
> > 
> > 





From owner-aaa-bof@merit.edu  Thu Jan 25 10:34:22 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00522
	for <aaa-archive@odin.ietf.org>; Thu, 25 Jan 2001 10:34:21 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 776EB5DEBD; Thu, 25 Jan 2001 10:32:55 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 552A65DEE3; Thu, 25 Jan 2001 10:32:55 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 12E4C5DEBD
	for <aaa-wg@merit.edu>; Thu, 25 Jan 2001 10:32:54 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA04518;
	Thu, 25 Jan 2001 07:32:51 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04122;
	Thu, 25 Jan 2001 07:32:50 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA12643;
	Thu, 25 Jan 2001 07:32:48 -0800 (PST)
Date: Thu, 25 Jan 2001 07:32:48 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: Re: [AAA-WG]: New proposed text for Destination-NAI
To: David Spence <DSpence@Interlinknetworks.com>
Cc: Pat Calhoun <pcalhoun@nasnfs.eng.sun.com>, aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <3A700AD3.52D4668D@Interlinknetworks.com>
Message-ID: <Roam.SIMC.2.0.6.980436768.11130.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Dave,

as usual :), you are correct on both points. I will modify the text
accordingly.

Thanks,

PatC
----
> Pat Calhoun wrote:
> > 
> > All,
> > 
> > As discussed in the past couple of days, some mechanism is required for STI
> > and other server initiated re-auth messages to find its way to the proper NAS.
> > The following text is what I would propose in the next I-D:
> > 
> > Comments (please!),
> 
> Well, for starters, I would suggest replacing the terms "Network Access
> Server (NAS)" and "NAS" where they appear with the term "DIAMETER client" as
> defined in section 1.0.  This is, after all, the base protocol -- not the
> NASREQ extension.
> 
> Next, I think it might help to say something about how an AAA server would
> know what value to assign to the Destination-NAI AVP.  Presumably it should
> be set to the value of the Host-Name AVP that appeared in the message from
> the DIAMETER client that established the session.  Correct?
> 
> > 
> > PatC
> > ----
> > 6.8  Finding a Target NAS within a Domain
> > 
> >    The DIAMETER protocol supports unsolicited server initiated messages.
> >    However, when such messages are transmitted, they have a specific
> >    target Network Access Server (NAS) in mind. Unsolicited server
> >    initiated messages are unique in that they contain the Destination-
> >    NAI AVP. Routing of such messages follow the same set of guidelines
> >    described in section 6.0, with one exception. When a proxy server has
> >    determined that a message, which includes the Destination-NAI AVP,
> >    has reached its target realm, the Destination-NAI AVP is used to
> >    identify the actual NAS the message should be forwarded to.
> > 
> > 6.8.1  Destination-NAI AVP
> > 
> >    The Destination-NAI AVP (AVP Code 293) [1] is of type OctetString,
> >    and contains the NAI [8] of the intended recipient of the message.
> >    This AVP MUST be present in all unsolicited server initiated
> >    messages.
> 
> -- 
> David Spence                            email: DSpence@Interlinknetworks.com
> Interlink Networks, Inc.                phone: (734) 821-1203
> 775 Technology Drive, Suite 200         fax:   (734) 821-1235
> Ann Arbor, MI 48108           
> U.S.A.
> 





From owner-aaa-bof@merit.edu  Thu Jan 25 14:37:41 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06867
	for <aaa-archive@odin.ietf.org>; Thu, 25 Jan 2001 14:37:40 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id D78DF5DEEB; Thu, 25 Jan 2001 14:37:06 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9E4645DE40; Thu, 25 Jan 2001 14:37:06 -0500 (EST)
Received: from gate.internaut.com (unknown [64.38.134.108])
	by segue.merit.edu (Postfix) with ESMTP id 034FC5DE40
	for <aaa-wg@merit.edu>; Thu, 25 Jan 2001 14:37:03 -0500 (EST)
Received: from e1kj2 (kidneybean [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0PJWdR02816
	for <aaa-wg@merit.edu>; Thu, 25 Jan 2001 11:32:39 -0800
From: "Bernard Aboba" <aboba@internaut.com>
To: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: [AAA-WG]: Request for discussion: ABNF changes to DIAMETER drafts
Date: Thu, 25 Jan 2001 11:37:11 -0800
Message-ID: <OJEJKOMOEAKLMOILFCPJOEIHDPAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

The RADIUS RFCs contain a table at the end, detailing which
AVPs can and cannot be included in each message. The current
DIAMETER drafts have not included such information, 
effectively leaving the syntax of DIAMETER messages
undefined. 

We need to fix this. The question is how. Erik Guttman
has proposed some fixes to the BNF format used in
the existing specs, in order to clarify the issue. 

This is a request for discussion on whether these
proposed changes should be applied to the documents
or whether another approach should be taken. 

If we do not hear objections to the changes by 
Friday, February 2, 2001 then the changes will
be incorporated into the DIAMETER specs. 



From owner-aaa-bof@merit.edu  Thu Jan 25 14:48:24 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07371
	for <aaa-archive@odin.ietf.org>; Thu, 25 Jan 2001 14:48:23 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 78BF15DEDC; Thu, 25 Jan 2001 14:44:37 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id BE4A25DEEA; Thu, 25 Jan 2001 14:44:36 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id BB26C5DEDC
	for <aaa-wg@merit.edu>; Thu, 25 Jan 2001 14:44:07 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA24496;
	Thu, 25 Jan 2001 11:44:01 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25839;
	Thu, 25 Jan 2001 11:43:56 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id LAA16500;
	Thu, 25 Jan 2001 11:43:41 -0800 (PST)
Date: Thu, 25 Jan 2001 11:43:42 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: Re: [AAA-WG]: Request for discussion: ABNF changes to DIAMETER drafts
To: Bernard Aboba <aboba@internaut.com>
Cc: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <OJEJKOMOEAKLMOILFCPJOEIHDPAA.aboba@internaut.com>
Message-ID: <Roam.SIMC.2.0.6.980451822.10970.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> The RADIUS RFCs contain a table at the end, detailing which
> AVPs can and cannot be included in each message. The current
> DIAMETER drafts have not included such information, 
> effectively leaving the syntax of DIAMETER messages
> undefined. 
> 
> We need to fix this. The question is how. Erik Guttman
> has proposed some fixes to the BNF format used in
> the existing specs, in order to clarify the issue. 
> 
> This is a request for discussion on whether these
> proposed changes should be applied to the documents
> or whether another approach should be taken. 
> 
> If we do not hear objections to the changes by 
> Friday, February 2, 2001 then the changes will
> be incorporated into the DIAMETER specs. 
> 
Just to refresh everyone's memory, Here is the proposed format definition:

2.2  Command Code Message Definitions

   All DIAMETER Command Code MUST include a corresponding ABNF
   specification, which is used to define the AVPs that MUST and MAY
   be present.  The following format is used in the definition:

      command-def      = command-name "::=" diameter-message

      diameter-name    = ALPHA *(ALPHA / DIGIT / "-")

      command-name     = diameter-name
                          ; The command-name has to be Command name,
                          ; defined in the base or extended DIAMETER
                          ; specifications.

      diameter-message = header  [ *fixed] [ *required] [ *optional] [ *fixed]

      header           = "<DIAMETER-Header:" command-id ">"

      fixed            = [qual] "<" avp-spec ">"

      required         = [qual] "{" avp-spec "}"

      optional         = [qual] "[" avp-name "]"
                          ; The avp-name in the 'optional' rule cannot
                          ; evaluate to any AVP Name which is included
                          ; in a fixed or required rule.

      qual             = [min] "*" [max]
                          ; See ABNF conventions, RFC 2234 section 3.6.
                          ; The absence of any qualifiers implies that one
                          ; and only one such AVP MUST be present.
                          ;
                          ; NOTE:  "[" and "]" have a different meaning
                          ; than in ABNF (see the optional rule, above).
                          ; These braces cannot be used to express an
                          ; optional fixed rules (such as an optional
                          ; ICV at the end.)  To do this, the convention
                          ; is '0*1fixed'.

      min              = 1*DIGIT
                          ; The minimum number of times the element may
                          ; be present.

      max              = 1*DIGIT
                          ; The maximum number of times the element may
                          ; be present.

      avp-spec         = diameter-name
                          ; The avp-spec has to be an AVP Name, defined
                          ; in the base or extended DIAMETER
                          ; specifications.

      avp-name         = avp-spec | "AVP"
                          ; The string "AVP" stands for *any* arbitrary
                          ; AVP Name, which does not conflict with the
                          ; required or fixed position AVPs defined in
                          ; the command code definition.

   The following is a definition of a fictitious command code:

      Example-Command ::= < DIAMETER-Header: 9999999 >
                          { User-Name }
                        * { Host-Name }
                        * [ AVP ]
                       0*1< Integrity-Check-Vector >


An example would be the MRI, which would look like:

      <Message-Reject-Ind message> ::= < DIAMETER Header: 259 >
                                       { Result-Code }
                                       { Host-Name }
                                       { Error-Reporting-NAI }
                                       [ Session-Id ]
                                       [ Failed-Command-Code ]
                                       [ Failed-AVP ]
                                     * [ AVP ]
                                     * [ Proxy-State ]
                                     * [ Route-Record ]
                                     * [ Routing-Realm ]
                                    0*1< Integrity-Check-Value >


PatC




From owner-aaa-bof@merit.edu  Thu Jan 25 22:07:49 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14872
	for <aaa-archive@odin.ietf.org>; Thu, 25 Jan 2001 22:07:48 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 5589B5E03F; Thu, 25 Jan 2001 22:07:01 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 353D85E038; Thu, 25 Jan 2001 22:07:01 -0500 (EST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by segue.merit.edu (Postfix) with ESMTP id C79BD5DE13
	for <aaa-wg@merit.edu>; Thu, 25 Jan 2001 22:06:59 -0500 (EST)
Received: from proxy2.cisco.com (proxy2.cisco.com [192.31.7.89])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id TAA07315;
	Thu, 25 Jan 2001 19:07:12 -0800 (PST)
Received: from osnet.ne.jp (emerald.osnet.ne.jp [210.227.149.146])
	by proxy2.cisco.com (8.11.2/8.11.2) with ESMTP id f0Q36tb09479;
	Thu, 25 Jan 2001 19:06:56 -0800 (PST)
Received: from dsisd898 ([64.24.247.127])
	by osnet.ne.jp (8.9.3/8.8.8) with ESMTP id LAA41061;
	Fri, 26 Jan 2001 11:57:50 +0900 (JST)
	(envelope-from pianoman@angelfire.com)
Message-Id: <200101260257.LAA41061@osnet.ne.jp>
From: "Melvin Dupont" <pianoman@angelfire.com>
Subject: [AAA-WG]: Only a Few More Openings #3428
To: today78u@osnet.ne.jp
X-Mailer: Microsoft Outlook Express 4..72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3
Mime-Version: 1.0
Date: Thu, 25 Jan 2001 19:44:20 -0500
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA14872

*Earn $2000 - $5000 weekly-starting within 1-4 weeks
*78% Profit Paid Daily
*No Selling
*No Risk Guarantee
*Work from home, No overhead, or employees.
*High Tech Training & Support
*Not MLM, 100x more profitable
*Multibillion Dollar Travel Industry
 
The most incredible part of our business
is that ALL MY CLIENTS CALL ME!
 
DO YOU QUALIFY FOR OUR MENTOR PROGRAM?
ACCEPTING ONLY 12 NEW ASSOCIATES
 
This is not a hobby!  Serious Inquires Only!!

Please reply with the following information 
NAME:
EMAIL ADDRESS:
PHONE:             (Required)
BEST TIME TO CALL:

TO:
mailto:ytzz@cmpmail.com?subject=tell_me_more
////////////////////////////////////////////////////
Please remove at:
mailto:theater@building.com?subject=remove
////////////////////////////////////////////////////






From owner-aaa-bof@merit.edu  Fri Jan 26 09:43:43 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11858
	for <aaa-archive@odin.ietf.org>; Fri, 26 Jan 2001 09:43:43 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id E5CFC5DD8C; Fri, 26 Jan 2001 09:43:24 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id D2A2D5DD9D; Fri, 26 Jan 2001 09:43:24 -0500 (EST)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 893B75DD8C
	for <aaa-wg@merit.edu>; Fri, 26 Jan 2001 09:43:23 -0500 (EST)
Received: from gwzpc (ams-vpdn-client-238.cisco.com [144.254.46.239]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id GAA23338; Fri, 26 Jan 2001 06:41:28 -0800 (PST)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Bernard Aboba" <aboba@internaut.com>,
        "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Request for discussion: ABNF changes to DIAMETER drafts
Date: Fri, 26 Jan 2001 06:35:52 -0800
Message-ID: <NDBBIHMPILAAGDHPCIOPOECIDCAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <OJEJKOMOEAKLMOILFCPJOEIHDPAA.aboba@internaut.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bernard Aboba [mailto:aboba@internaut.com] writes:

> The RADIUS RFCs contain a table at the end, detailing which
> AVPs can and cannot be included in each message. The current
> DIAMETER drafts have not included such information,
> effectively leaving the syntax of DIAMETER messages
> undefined.
>
> We need to fix this. The question is how. Erik Guttman
> has proposed some fixes to the BNF format used in
> the existing specs, in order to clarify the issue.
>
> This is a request for discussion on whether these
> proposed changes should be applied to the documents
> or whether another approach should be taken.

Personally, I like the table approach.  It has the virtues of extreme
simplicity and clarity.  Of corse, it says nothing about how the semantics
of AVPs interact, but given that well-designed AVPs are both declaritive and
semantically idempotent (except for groupings of AVPs designed to describe
an instance of abstract entities), this should not be an issue.

>
> If we do not hear objections to the changes by
> Friday, February 2, 2001 then the changes will
> be incorporated into the DIAMETER specs.
>
>




From owner-aaa-bof@merit.edu  Fri Jan 26 09:59:12 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12025
	for <aaa-archive@odin.ietf.org>; Fri, 26 Jan 2001 09:59:12 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 184DE5DE31; Fri, 26 Jan 2001 09:58:55 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 082045DE35; Fri, 26 Jan 2001 09:58:54 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id A9A865DE31
	for <aaa-wg@merit.edu>; Fri, 26 Jan 2001 09:58:53 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13121;
	Fri, 26 Jan 2001 06:58:41 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA27336;
	Fri, 26 Jan 2001 06:58:40 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id GAA28083;
	Fri, 26 Jan 2001 06:58:36 -0800 (PST)
Date: Fri, 26 Jan 2001 06:58:36 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: RE: [AAA-WG]: Request for discussion: ABNF changes to DIAMETER drafts
To: gwz@cisco.com
Cc: Bernard Aboba <aboba@internaut.com>,
        "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <NDBBIHMPILAAGDHPCIOPOECIDCAA.gwz@cisco.com>
Message-ID: <Roam.SIMC.2.0.6.980521116.31158.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Personally, I like the table approach.  It has the virtues of extreme
> simplicity and clarity.  Of corse, it says nothing about how the semantics
> of AVPs interact, but given that well-designed AVPs are both declaritive and
> semantically idempotent (except for groupings of AVPs designed to describe
> an instance of abstract entities), this should not be an issue.

Interesting view. As a developer of RADIUS (or ex- :), I have always found
that having to move to the end of the document to find out what belongs in a
particular message to be ackward. As I am working on a particular command, I
want everything in front on me.

So in RADIUS, we have a table that spans multiple pages, such as:

   The following table provides a guide to which attributes may be found
   in Accounting-Request packets.  No attributes should be found in
   Accounting-Response packets except Proxy-State and possibly Vendor-
   Specific.

                      #     Attribute
                      0-1   User-Name
                      0     User-Password
                      0     CHAP-Password
                      0-1   NAS-IP-Address [5]
                      0-1   NAS-Port
                      0-1   Service-Type
                      0-1   Framed-Protocol
                      0-1   Framed-IP-Address
                      0-1   Framed-IP-Netmask
                      0-1   Framed-Routing
                      0+    Filter-Id
                      0-1   Framed-MTU
[ad nauseum]

(btw, Given that some DIAMETER extensions have as many as 5 or 6 commands, the
table would obviously be structured differently. In RADIUS this was simple due
to the small number of commands that can include attributes, or 1).

In DIAMETER, the approach we've taken is each individual command, while being
defined, contains the ABNF as follows:

      <Message-Reject-Ind message> ::= < DIAMETER Header: 259 >
                                       { Result-Code }
                                       { Host-Name }
                                       { Error-Reporting-NAI }
                                       [ Session-Id ]
                                       [ Failed-Command-Code ]
                                       [ Failed-AVP ]
                                     * [ AVP ]
                                     * [ Proxy-State ]
                                     * [ Route-Record ]
                                     * [ Routing-Realm ]
                                    0*1< Integrity-Check-Value >


(or course, there is a section that defines the ABNF format). 

I, personally, find this so much simpler since everything is in front of you,
and there is no chance of missing something in the table. HOwever, I am
willing to heard from others.

PatC




From owner-aaa-bof@merit.edu  Fri Jan 26 10:58:54 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12735
	for <aaa-archive@odin.ietf.org>; Fri, 26 Jan 2001 10:58:54 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 6E1285DE46; Fri, 26 Jan 2001 10:58:32 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 59B165DE65; Fri, 26 Jan 2001 10:58:32 -0500 (EST)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id E86435DE46
	for <aaa-wg@merit.edu>; Fri, 26 Jan 2001 10:58:30 -0500 (EST)
Received: from gwzpc (ams-vpdn-client-238.cisco.com [144.254.46.239]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id HAA23160; Fri, 26 Jan 2001 07:56:35 -0800 (PST)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.eng.sun.com>
Cc: "Bernard Aboba" <aboba@internaut.com>,
        "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Request for discussion: ABNF changes to DIAMETER drafts
Date: Fri, 26 Jan 2001 07:46:45 -0800
Message-ID: <NDBBIHMPILAAGDHPCIOPMECMDCAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <Roam.SIMC.2.0.6.980521116.31158.pcalhoun@nasnfs>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com] writes:

> > Personally, I like the table approach.  It has the virtues of extreme
> > simplicity and clarity.  Of corse, it says nothing about how
> the semantics
> > of AVPs interact, but given that well-designed AVPs are both
> declaritive and
> > semantically idempotent (except for groupings of AVPs designed
> to describe
> > an instance of abstract entities), this should not be an issue.
>
> Interesting view. As a developer of RADIUS (or ex- :), I have always found
> that having to move to the end of the document to find out what
> belongs in a
> particular message to be ackward. As I am working on a particular
> command, I
> want everything in front on me.

Recently, those smart software people have developed these things called
"windows".  Apparently, some systems even allow you to have view different
parts of the _same_ file in _two_ "windows" at once! ;-)

>
> So in RADIUS, we have a table that spans multiple pages, such as:
>
>    The following table provides a guide to which attributes may be found
>    in Accounting-Request packets.  No attributes should be found in
>    Accounting-Response packets except Proxy-State and possibly Vendor-
>    Specific.
>
>                       #     Attribute
>                       0-1   User-Name
>                       0     User-Password
>                       0     CHAP-Password
>                       0-1   NAS-IP-Address [5]
>                       0-1   NAS-Port
>                       0-1   Service-Type
>                       0-1   Framed-Protocol
>                       0-1   Framed-IP-Address
>                       0-1   Framed-IP-Netmask
>                       0-1   Framed-Routing
>                       0+    Filter-Id
>                       0-1   Framed-MTU
> [ad nauseum]
>
> (btw, Given that some DIAMETER extensions have as many as 5 or 6
> commands, the
> table would obviously be structured differently. In RADIUS this
> was simple due
> to the small number of commands that can include attributes, or 1).
>
> In DIAMETER, the approach we've taken is each individual command,
> while being
> defined, contains the ABNF as follows:

In other words, "In Diameter, we have ABNF-like stuff spanning several
pages..."

>
>       <Message-Reject-Ind message> ::= < DIAMETER Header: 259 >
>                                        { Result-Code }
>                                        { Host-Name }
>                                        { Error-Reporting-NAI }
>                                        [ Session-Id ]
>                                        [ Failed-Command-Code ]
>                                        [ Failed-AVP ]
>                                      * [ AVP ]
>                                      * [ Proxy-State ]
>                                      * [ Route-Record ]
>                                      * [ Routing-Realm ]
>                                     0*1< Integrity-Check-Value >
>
>
> (or course, there is a section that defines the ABNF format).
>
> I, personally, find this so much simpler since everything is in
> front of you,
> and there is no chance of missing something in the table. HOwever, I am
> willing to heard from others.

Whatever.

>
> PatC
>
>




From owner-aaa-bof@merit.edu  Fri Jan 26 14:35:50 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19514
	for <aaa-archive@odin.ietf.org>; Fri, 26 Jan 2001 14:35:49 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 6F2485DEC7; Fri, 26 Jan 2001 14:35:33 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 571E05DEF8; Fri, 26 Jan 2001 14:35:33 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 007C55DEC7
	for <aaa-wg@merit.edu>; Fri, 26 Jan 2001 14:35:31 -0500 (EST)
Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA14170;
	Fri, 26 Jan 2001 11:35:29 -0800 (PST)
Received: from vayne (muc-isdn-15 [129.157.164.115])
	by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1) with SMTP id UAA00277;
	Fri, 26 Jan 2001 20:35:27 +0100 (MET)
Date: Fri, 26 Jan 2001 20:45:59 +0100 (MET)
From: Erik Guttman <Erik.Guttman@germany.sun.com>
Reply-To: Erik Guttman <Erik.Guttman@germany.sun.com>
Subject: RE: [AAA-WG]: Request for discussion: ABNF changes to DIAMETER drafts
To: gwz@cisco.com
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        Bernard Aboba <aboba@internaut.com>,
        "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <NDBBIHMPILAAGDHPCIOPMECMDCAA.gwz@cisco.com>
Message-ID: <Roam.SIMC.2.0.6.980538359.8201.erikg@ehdb03-home.germany>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


> > Glen writes: 
> > > Personally, I like the table approach.  It has the virtues of extreme
> > > simplicity and clarity. 

> Pat responds:
> > So in RADIUS, we have a table that spans multiple pages, such as:

Glen ripostes:
> In other words, "In Diameter, we have ABNF-like stuff spanning several
> pages..."

Glen has a point - a table may be all we need here.  There are two
additional things we need to bring out in our formal presentation
of DIAMETER, though.  

We need to say that certain AVPs MUST come first (or last).  We also 
need to specify that although optional AVPs can be included, mixed in 
with required AVPs in any order, these MUST NOT break the rules 
regarding how many AVPs of certain kinds may appear.  Like if the 
rule says one and only one Z AVP has to be in a message, we can't
include another couple Z AVPs as 'optional' AVPs in the message.
This would have to be stated formally of course, and that's the
hard part.

Erik




From owner-aaa-bof@merit.edu  Fri Jan 26 15:52:12 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21360
	for <aaa-archive@odin.ietf.org>; Fri, 26 Jan 2001 15:52:11 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 5A9855DEFC; Fri, 26 Jan 2001 15:51:55 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 482E75DEF8; Fri, 26 Jan 2001 15:51:55 -0500 (EST)
Received: from web1.merit.edu (web1.merit.edu [198.108.62.192])
	by segue.merit.edu (Postfix) with ESMTP id 3E8495DEF7
	for <aaa-wg@merit.edu>; Fri, 26 Jan 2001 15:51:54 -0500 (EST)
Received: (from web@localhost)
	by web1.merit.edu (8.9.3/8.9.1) id PAA07558
	for aaa-wg@merit.edu; Fri, 26 Jan 2001 15:51:54 -0500 (EST)
Date: Fri, 26 Jan 2001 15:51:54 -0500
From: William Bulley <web@merit.edu>
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Good News! (about the Merit archives)
Message-ID: <20010126155153.L6675@web1.merit.edu>
Mail-Followup-To: aaa-wg@merit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1us
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

As Dave Mitton has previously stated, we have the Merit AAA-WG
archives "homed" in a new location:

   http://www.merit.edu/mail.archives/aaa-wg/

(as a by-product of this, we have said "bye bye" to the aaa-bof
stuff on www.merit.edu)

The new news is that we have just added a spiffy new search
capability (well, spiffy may be a bit over-blown...) for the
aaa-wg mail archives.  Same URL but the search feature is in
the upper right corner now.  Check it out!  I tried to find
"web" and, boy, was I surprised how overloaded that word is!  :-)

Regards,

web...

-- 
William Bulley                     Manager of Software Engineering
Merit Network, Inc.                Email: web@merit.edu
Building One, Suite 2000           Phone: (734) 764-9430
4251 Plymouth Road                 Fax:   (734) 647-3185
Ann Arbor, Michigan  48105-2785

"We're not C++ programmers.  There is one program written in C++
in OpenBSD, out of 300 megabytes of source code." - Theo deRaadt,
father and principal archtitect of the OpenBSD operating system.



From owner-aaa-bof@merit.edu  Fri Jan 26 16:33:59 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22740
	for <aaa-archive@odin.ietf.org>; Fri, 26 Jan 2001 16:33:59 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 19AEA5DEF7; Fri, 26 Jan 2001 16:30:59 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 004805DF06; Fri, 26 Jan 2001 16:30:58 -0500 (EST)
Received: from gate.internaut.com (unknown [64.38.134.108])
	by segue.merit.edu (Postfix) with ESMTP id 07EDE5DEF7
	for <aaa-wg@merit.edu>; Fri, 26 Jan 2001 16:30:57 -0500 (EST)
Received: from e1kj2 (kidneybean [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0QLD9R22365;
	Fri, 26 Jan 2001 13:13:10 -0800
From: "Bernard Aboba" <aboba@internaut.com>
To: "Erik Guttman" <Erik.Guttman@germany.sun.com>, <gwz@cisco.com>
Cc: "Patrice Calhoun" <pcalhoun@nasnfs.eng.sun.com>,
        "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Request for discussion: ABNF changes to DIAMETER drafts
Date: Fri, 26 Jan 2001 13:17:49 -0800
Message-ID: <OJEJKOMOEAKLMOILFCPJCELDDPAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Roam.SIMC.2.0.6.980538359.8201.erikg@ehdb03-home.germany>
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>Glen has a point - a table may be all we need here.  

The table is nice and simple and might be useful no matter
what else we do. But there may be situations which cannot be covered
in the table. So how do we specify those?

>We need to say that certain AVPs MUST come first (or last).  

I can think up a couple of things that haven't yet been discussed
that would fit in this category. How do you specify, for example,
that certain AVPs occur first in the message, and must not be
encrypted (e.g. message type, destination NAI, etc.)



From owner-aaa-bof@merit.edu  Fri Jan 26 17:34:48 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23601
	for <aaa-archive@odin.ietf.org>; Fri, 26 Jan 2001 17:34:47 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 9A65B5DF04; Fri, 26 Jan 2001 17:34:19 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 81ADC5DD90; Fri, 26 Jan 2001 17:34:19 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id C31435DF04
	for <aaa-wg@merit.edu>; Fri, 26 Jan 2001 17:34:17 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02052;
	Fri, 26 Jan 2001 13:36:51 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06634;
	Fri, 26 Jan 2001 13:36:50 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA06185;
	Fri, 26 Jan 2001 13:36:46 -0800 (PST)
Date: Fri, 26 Jan 2001 13:36:46 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: RE: [AAA-WG]: Request for discussion: ABNF changes to DIAMETER drafts
To: Bernard Aboba <aboba@internaut.com>
Cc: Erik Guttman <Erik.Guttman@germany.sun.com>, gwz@cisco.com,
        Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <OJEJKOMOEAKLMOILFCPJCELDDPAA.aboba@internaut.com>
Message-ID: <Roam.SIMC.2.0.6.980545006.23908.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> >Glen has a point - a table may be all we need here.  
> 
> The table is nice and simple and might be useful no matter
> what else we do. But there may be situations which cannot be covered
> in the table. So how do we specify those?
> 
> >We need to say that certain AVPs MUST come first (or last).  
> 
> I can think up a couple of things that haven't yet been discussed
> that would fit in this category. How do you specify, for example,
> that certain AVPs occur first in the message, and must not be
> encrypted (e.g. message type, destination NAI, etc.)

Correct. There are a couple of ordering rules, and these are REALLY hard to
put in a table. Of course, you can add text throughout the document, in the
actual AVP descriptions, but that, again, just makes it harder to find.

However, Glen really likes tables, and Erik seems to agree.

Both? Where the table is just a quick reference?

PatC




From owner-aaa-bof@merit.edu  Sat Jan 27 01:09:25 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01320
	for <aaa-archive@odin.ietf.org>; Sat, 27 Jan 2001 01:09:24 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id AC35D5DF2F; Sat, 27 Jan 2001 01:08:59 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 92D8B5DE83; Sat, 27 Jan 2001 01:08:59 -0500 (EST)
Received: from gate.internaut.com (unknown [64.38.134.108])
	by segue.merit.edu (Postfix) with ESMTP id E8AF55DDDE
	for <aaa-wg@merit.edu>; Sat, 27 Jan 2001 01:08:57 -0500 (EST)
Received: from e1kj2 (kidneybean [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0R64LR19051;
	Fri, 26 Jan 2001 22:04:21 -0800
From: "Bernard Aboba" <aboba@internaut.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.eng.sun.com>
Cc: "Erik Guttman" <Erik.Guttman@germany.sun.com>, <gwz@cisco.com>,
        "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Request for discussion: ABNF changes to DIAMETER drafts
Date: Fri, 26 Jan 2001 22:09:03 -0800
Message-ID: <OJEJKOMOEAKLMOILFCPJEELKDPAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Roam.SIMC.2.0.6.980545006.23908.pcalhoun@nasnfs>
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>Both? Where the table is just a quick reference?

Do both, but make sure they agree ;)





From owner-aaa-bof@merit.edu  Sat Jan 27 06:44:56 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15063
	for <aaa-archive@odin.ietf.org>; Sat, 27 Jan 2001 06:44:56 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id EE9FF5DD95; Sat, 27 Jan 2001 06:44:35 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id D22CD5DDB5; Sat, 27 Jan 2001 06:44:35 -0500 (EST)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 13F115DD95
	for <aaa-wg@merit.edu>; Sat, 27 Jan 2001 06:44:34 -0500 (EST)
Received: from gwzpc (ams-vpdn-client-238.cisco.com [144.254.46.239]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id DAA01938; Sat, 27 Jan 2001 03:42:43 -0800 (PST)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Bernard Aboba" <aboba@internaut.com>,
        "Erik Guttman" <Erik.Guttman@germany.sun.com>
Cc: "Patrice Calhoun" <pcalhoun@nasnfs.eng.sun.com>,
        "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Request for discussion: ABNF changes to DIAMETER drafts
Date: Sat, 27 Jan 2001 03:41:01 -0800
Message-ID: <NDBBIHMPILAAGDHPCIOPMEDJDCAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <OJEJKOMOEAKLMOILFCPJCELDDPAA.aboba@internaut.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bernard Aboba [mailto:aboba@internaut.com] writes:

> >Glen has a point - a table may be all we need here.  
> 
> The table is nice and simple and might be useful no matter
> what else we do. But there may be situations which cannot be covered
> in the table. So how do we specify those?
> 
> >We need to say that certain AVPs MUST come first (or last).  
> 
> I can think up a couple of things that haven't yet been discussed
> that would fit in this category. How do you specify, for example,
> that certain AVPs occur first in the message, and must not be
> encrypted (e.g. message type, destination NAI, etc.)

(Continuing in semi-smartass mode)  How about English?  

> 



From owner-aaa-bof@merit.edu  Sat Jan 27 13:19:03 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17248
	for <aaa-archive@odin.ietf.org>; Sat, 27 Jan 2001 13:19:03 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 36A215DF82; Sat, 27 Jan 2001 13:16:08 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 178745DF81; Sat, 27 Jan 2001 13:16:08 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 7B7A85DF7E
	for <aaa-wg@merit.edu>; Sat, 27 Jan 2001 13:16:06 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15048;
	Sat, 27 Jan 2001 10:15:58 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13256;
	Sat, 27 Jan 2001 10:15:32 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA21527;
	Sat, 27 Jan 2001 10:15:27 -0800 (PST)
Date: Sat, 27 Jan 2001 10:15:28 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: RE: [AAA-WG]: Request for discussion: ABNF changes to DIAMETER drafts
To: gwz@cisco.com
Cc: Bernard Aboba <aboba@internaut.com>,
        Erik Guttman <Erik.Guttman@germany.sun.com>,
        Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <NDBBIHMPILAAGDHPCIOPMEDJDCAA.gwz@cisco.com>
Message-ID: <Roam.SIMC.2.0.6.980619328.10582.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Bernard Aboba [mailto:aboba@internaut.com] writes:
> 
> > >Glen has a point - a table may be all we need here.  
> > 
> > The table is nice and simple and might be useful no matter
> > what else we do. But there may be situations which cannot be covered
> > in the table. So how do we specify those?
> > 
> > >We need to say that certain AVPs MUST come first (or last).  
> > 
> > I can think up a couple of things that haven't yet been discussed
> > that would fit in this category. How do you specify, for example,
> > that certain AVPs occur first in the message, and must not be
> > encrypted (e.g. message type, destination NAI, etc.)
> 
> (Continuing in semi-smartass mode)  How about English?  

Of course, that would be the language of choise. The issue, though (again) is
whether distributed information like this would ease interoperability, as
opposed to a central location (e.g. per message).

Again, I am flexible. I'll do what the WG wants.

PatC




From owner-aaa-bof@merit.edu  Sun Jan 28 22:40:37 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13504
	for <aaa-archive@odin.ietf.org>; Sun, 28 Jan 2001 22:40:37 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 63E5E5DD8F; Sun, 28 Jan 2001 22:40:14 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 4E3835DDAA; Sun, 28 Jan 2001 22:40:14 -0500 (EST)
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by segue.merit.edu (Postfix) with SMTP id 3EE9A5DD8F
	for <aaa-wg@merit.edu>; Sun, 28 Jan 2001 22:40:13 -0500 (EST)
Received: (qmail 2013 invoked by uid 500); 29 Jan 2001 04:13:53 -0000
Date: Sun, 28 Jan 2001 22:13:52 -0600
From: David Frascone <dave@frascone.com>
To: aaa-wg@merit.edu
Subject: [AAA-WG]: OctetString type
Message-ID: <20010128221352.C1427@newman.frascone.com>
Mail-Followup-To: aaa-wg@merit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-encrypt-payload: no
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

I think removing the basic string type was a bad idea.  With octet string,
there is no easy way to tell if the data is printable.  It was nice having
a string type, since the data could be printed in log messages, debug
strings, etc.

I think we should still have two types, Octets, and String, and treat them
appropriately.

Granted, on the transport side, DIAMETER will treat the two equaly, but it
makes debugging/logging much nicer to know when you can print out the
data involved.

Just my $.02 worth.


-Dave



From owner-aaa-bof@merit.edu  Mon Jan 29 12:56:41 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06765
	for <aaa-archive@odin.ietf.org>; Mon, 29 Jan 2001 12:56:40 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 240505DFB5; Mon, 29 Jan 2001 12:54:39 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id EE5195DFA0; Mon, 29 Jan 2001 12:54:38 -0500 (EST)
Received: from funk.funk.com (funk.funk.com [198.186.160.66])
	by segue.merit.edu (Postfix) with ESMTP id 50E325DF9D
	for <aaa-wg@merit.edu>; Mon, 29 Jan 2001 12:54:37 -0500 (EST)
Received: from pii400 (pii400.funk.com [198.186.160.46])
	by funk.funk.com (8.8.5/8.8.5) with SMTP id MAA16994;
	Mon, 29 Jan 2001 12:21:21 -0500 (EST)
Message-Id: <4.1.20010129113831.01bef5b0@funk1.funk.com>
X-Sender: paul@funk1.funk.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 29 Jan 2001 12:36:53 -0500
To: David Frascone <dave@frascone.com>, aaa-wg@merit.edu
From: Paul Funk <paul@funk.com>
Subject: Re: [AAA-WG]: OctetString type
In-Reply-To: <20010128221352.C1427@newman.frascone.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

I agree that String should be a type.

There will be numerous AVPs whose values must be human readable. In 
the text of the AVP's description, rather than specifying type as OctetString, 
then qualifying it to be "human readable UTF-8 character string", why not just 
just call a String a String?

A Diameter implementation needs to know an AVP's type not only for 
processing purposes but also for administrative purposes, e.g., logging 
and configuration. While it is always possible to qualify the use of an 
AVP further in its description, it promotes precision and clarity to formally 
define types for common data formats.

I think Time is also a candidate for re-inclusion as a data type. 

The Alpha-2 draft already defines the use of UTF-8 as a subset of 
OctetString, and time data as a subset of Unsigned32. They might as 
well be defined separately as types in their own right.




At 10:13 PM 1/28/01 -0600, David Frascone wrote:
>I think removing the basic string type was a bad idea.  With octet string,
>there is no easy way to tell if the data is printable.  It was nice having
>a string type, since the data could be printed in log messages, debug
>strings, etc.
>
>I think we should still have two types, Octets, and String, and treat them
>appropriately.
>
>Granted, on the transport side, DIAMETER will treat the two equaly, but it
>makes debugging/logging much nicer to know when you can print out the
>data involved.
>
>Just my $.02 worth.
>
>
>-Dave




From owner-aaa-bof@merit.edu  Mon Jan 29 16:04:27 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10036
	for <aaa-archive@odin.ietf.org>; Mon, 29 Jan 2001 16:04:27 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 0DA8C5DE70; Mon, 29 Jan 2001 16:01:54 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id E91B75DE95; Mon, 29 Jan 2001 16:01:53 -0500 (EST)
Received: from dfw-smtpout4.email.verio.net (dfw-smtpout4.email.verio.net [129.250.36.44])
	by segue.merit.edu (Postfix) with ESMTP id C19755DE70
	for <aaa-wg@merit.edu>; Mon, 29 Jan 2001 16:01:52 -0500 (EST)
Received: from [129.250.38.62] (helo=dfw-mmp2.email.verio.net)
	by dfw-smtpout4.email.verio.net with esmtp
	id 14NLQm-0001h6-00; Mon, 29 Jan 2001 21:01:44 +0000
Received: from [206.133.83.14] (helo=localhost)
	by dfw-mmp2.email.verio.net with esmtp
	id 14NLQY-0002zy-00; Mon, 29 Jan 2001 21:01:31 +0000
X-Sender: misterprivacy@hushmail.com
From: Dave <misterprivacy@hushmail.com>
To: "customer" <misterprivacy@hushmail.com>
Date: Mon, 29 Jan 2001 12:18:00 -0500
Subject: [AAA-WG]: I could go to JAIL for selling this CD!
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001__2979830_44280.05"
Message-Id: <E14NLQY-0002zy-00@dfw-mmp2.email.verio.net>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

This is a Multipart MIME message.

------=_NextPart_000_001__2979830_44280.05
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit


------=_NextPart_000_001__2979830_44280.05
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: base64

PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9u
YWwvL2VuIj4NCjxodG1sPg0KPGhlYWQ+DQogICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50
LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4NCiAgIDxt
ZXRhIG5hbWU9IkdFTkVSQVRPUiIgY29udGVudD0iTW96aWxsYS80LjYxIFtlbl0gKFdpbjk4
OyBJKSBbTmV0c2NhcGVdIj4NCiAgIDx0aXRsZT5UaGUgQkFOTkVEIENEITwvdGl0bGU+DQo8
L2hlYWQ+DQo8Ym9keT4NCjxmb250IHNpemU9KzE+SGksPC9mb250Pg0KPHA+PGZvbnQgc2l6
ZT0rMT5JIGhhdmUgYmVlbiByZWNpZXZpbmcgZW1haWxzIHNheWluZyB0aGF0IEknbSBjb250
cmlidXRpbmcNCnRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+dGhlICJtb3JhbCBkZWNh
eSBvZiBzb2NpZXR5IiBieSBzZWxsaW5nIHRoZSBCYW5uZWQgQ0QuJm5ic3A7DQpUaGF0PC9m
b250Pg0KPGJyPjxmb250IHNpemU9KzE+bWF5IGJlLCBidXQgSSBmZWVsIHN0cm9uZ2x5IHRo
YXQgeW91IGhhdmUgYSByaWdodCB0bw0KYmVuZWZpdCBmcm9tPC9mb250Pg0KPGJyPjxmb250
IHNpemU9KzE+dGhpcyBoYXJkLXRvLWZpbmQgaW5mb3JtYXRpb24uPC9mb250Pg0KPHA+PGZv
bnQgY29sb3I9IiNDQzAwMDAiPjxmb250IHNpemU9KzE+U28gSSBhbSBnaXZpbmcgeW91IE9O
RSBMQVNUIENIQU5DRQ0KdG8gb3JkZXI8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9y
PSIjQ0MwMDAwIj48Zm9udCBzaXplPSsxPnRoZSBCYW5uZWQgQ0QhPC9mb250PjwvZm9udD4N
Cjxicj4mbmJzcDsNCjx0YWJsZSBCT1JERVI9MCBDT0xTPTIgV0lEVEg9Ijc1JSIgPg0KPHRy
Pg0KPHRkIFdJRFRIPSIxJSI+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2EuY29tL2lt
YWdlcy9zcHkuanBnIiBoZWlnaHQ9MTI4IHdpZHRoPTg2PjwvdGQ+DQoNCjx0ZD48Zm9udCBz
aXplPSsxPldpdGggdGhpcyBwb3dlcmZ1bCBDRCwgeW91IHdpbGwgYmUgYWJsZSB0byBpbnZl
c3RpZ2F0ZQ0KeW91ciBmcmllbmRzLCBlbmVtaWVzIGFuZCBsb3ZlcnMgaW4ganVzdCBtaW51
dGVzIHVzaW5nIHRoZSBJbnRlcm5ldC4mbmJzcDsNCllvdSBjYW4gdHJhY2sgZG93biBvbGQg
ZmxhbWVzIGZyb20gY29sbGVnZSwgb3IgeW91IGNhbiBkaWcgdXAgc29tZSBkaXJ0DQpvbiB5
b3VyIGJvc3MgdG8gbWFrZSBzdXJlIHlvdSBnZXQgdGhhdCBuZXh0IHByb21vdGlvbiE8L2Zv
bnQ+PC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KDQo8cD48Zm9udCBzaXplPSsxPk9yIG1heWJl
IHlvdSB3YW50IGEgZmFrZSBkaXBsb21hIHRvIGhhbmcgb24geW91ciBiZWRyb29tPC9mb250
Pg0KPGJyPjxmb250IHNpemU9KzE+d2FsbC4mbmJzcDsgWW91J2xsIGZpbmQgYWRkcmVzc2Vz
IGZvciBjb21wYW5pZXMgdGhhdA0KbWFrZSB0aGVzZTwvZm9udD4NCjxicj48Zm9udCBzaXpl
PSsxPmRpcGxvbWFzIG9uIHRoZSBCYW5uZWQgQ0QuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0r
MT5OZWVkIHRvIGRpc2FwcGVhciBmYXN0IGFuZCBuZXZlciBsb29rIGJhY2s/Jm5ic3A7IE5v
IHByb2JsZW0hPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+VXNpbmcgdGhlIEJhbm5lZCBD
RCwgeW91IHdpbGwgbGVhcm4gaG93IHRvIGJ1aWxkIGEgY29tcGxldGVseTwvZm9udD4NCjxi
cj48Zm9udCBzaXplPSsxPm5ldyBpZGVudGl0eS48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSsx
Pk9idmlvdXNseSwgdGhlIFBvd2VycyBUaGF0IEJlIGRvbid0IHdhbnQgeW91IHRvIGhhdmUg
dGhlPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+QmFubmVkIENELiZuYnNwOyBUaGV5IGhh
dmUgdGhyZWF0ZW5lZCBtZSB3aXRoIGxhd3N1aXRzLA0KZmluZXMsPC9mb250Pg0KPGJyPjxm
b250IHNpemU9KzE+YW5kIGV2ZW4gaW1wcmlzb25tZW50IHVubGVzcyBJIHN0b3Agc2VsbGlu
ZyBpdCBpbW1lZGlhdGVseS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5CdXQgSSBmZWVs
IHRoYXQgWU9VIGhhdmUgYSBDb25zdGl0dXRpb25hbCByaWdodCB0byBhY2Nlc3M8L2ZvbnQ+
DQo8YnI+PGZvbnQgc2l6ZT0rMT50aGlzIHR5cGUgb2YgaW5mb3JtYXRpb24sIGFuZCBJIGNh
bid0IGJlIGludGltaWRhdGVkLjwvZm9udD4NCjxicj4mbmJzcDsNCjx0YWJsZSBCT1JERVI9
MCBDT0xTPTIgV0lEVEg9IjUwJSIgPg0KPHRyPg0KPHRkIFdJRFRIPSIxMDAlIj48aT48Zm9u
dCBjb2xvcj0iIzMzMzNGRiI+PGZvbnQgc2l6ZT0rMT5VbmNsZSBTYW0gYW5kIHlvdXINCmNy
ZWRpdG9ycyBhcmUgaG9ycmlmaWVkIHRoYXQgSSBhbSBzdGlsbCBzZWxsaW5nIHRoaXMgcHJv
ZHVjdCEmbmJzcDsgVGhlcmUNCm11c3QgYmUgYSBwcmljZSBvbiBteSBoZWFkITwvZm9udD48
L2ZvbnQ+PC9pPjwvdGQ+DQoNCjx0ZCBXSURUSD0iMSUiPjxpbWcgU1JDPSJodHRwOi8vY29t
cHV6b25ldXNhLmNvbS9pbWFnZXMvb3V0bGF3LmpwZyIgaGVpZ2h0PTEyOCB3aWR0aD05Mz48
L3RkPg0KPC90cj4NCjwvdGFibGU+DQoNCjxwPjxmb250IHNpemU9KzE+V2h5IGFyZSB0aGV5
IHNvIHVwc2V0PyBCZWNhdXNlIHRoaXMgQ0QgZ2l2ZXMgeW91IGZyZWVkb20uPC9mb250Pg0K
PGJyPjxmb250IHNpemU9KzE+QW5kIHlvdSBjYW4ndCBidXkgZnJlZWRvbSBhdCB5b3VyIGxv
Y2FsIFdhbG1hcnQuJm5ic3A7DQpZb3Ugd2lsbDwvZm9udD4NCjxicj48Zm9udCBzaXplPSsx
PmhhdmUgdGhlIGZyZWVkb20gdG8gYXZvaWQgY3JlZGl0b3JzLCBqdWRnbWVudHMsIGxhd3N1
aXRzLA0KSVJTPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+dGF4IGNvbGxlY3RvcnMsIGNy
aW1pbmFsIGluZGljdG1lbnRzLCB5b3VyIGdyZWVkeSBleC13aWZlDQpvcjwvZm9udD4NCjxi
cj48Zm9udCBzaXplPSsxPmV4LWh1c2JhbmQsIGFuZCBNVUNIIG1vcmUhPC9mb250Pg0KPHA+
PGZvbnQgc2l6ZT0rMT5KdXN0IGxvb2sgYXQgc29tZSBvZiB0aGUgdGhpbmdzIHlvdSBjYW4g
ZG8gd2l0aCB0aGlzIENEDQouLi48L2ZvbnQ+DQo8dWw+DQo8bGk+DQo8Yj48Zm9udCBjb2xv
cj0iIzAwMDA5OSI+U2F2ZSBodW5kcmVkcyBvciBldmVuIHRob3VzYW5kcyBvZiBkb2xsYXJz
IG9uDQp5b3VyIHRheGVzIGJ5IHVzaW5nIHRoZSBzZWNyZXQgdGF4IHRpcHMgY29udGFpbmVk
IGluIHRoaXMgcGFja2FnZS4mbmJzcDsNClRoZSBJUlMgZG9lcyBOT1Qgd2FudCB5b3UgdG8g
a25vdyB0aGVzZSBsb29waG9sZXMhPC9mb250PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9u
dCBjb2xvcj0iIzAwMDA5OSI+VHJhY2sgZG93biBmcmllbmRzIGFuZCBvbGQgZmxhbWVzIGZy
b20gdGhlIGNvbWZvcnQNCm9mIHlvdXIgb3duIGhvbWUgd2l0aCBvdXIgSW50ZXJuZXQgaW52
ZXN0aWdhdGlvbiByZXNvdXJjZXMhPC9mb250PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9u
dCBjb2xvcj0iIzAwMDA5OSI+RmluZCBvdXQgd2hlcmUgeW91ciBFWCBpcyBoaWRpbmcgdGhl
aXIgbW9uZXkgdG8NCmF2b2lkIGFsaW1vbnksIGNoaWxkIHN1cHBvcnQsIG9yIGRpdm9yY2Ug
c2V0dGxlbWVudHMuIFRoZW4gZ2V0IHlvdXIgaGFuZHMNCm9uIHRoYXQgbW9uZXkuJm5ic3A7
IEJsZWVkICdlbSBkcnkhJm5ic3A7IFByaXZhdGUgaW52ZXN0aWdhdG9ycyBjaGFyZ2UNCnRo
b3VzYW5kcyBvZiBkb2xsYXJzIGZvciB0aGlzIHNlcnZpY2UsIGJ1dCB5b3UgY2FuIGRvIGl0
IHdpdGggYSBjb21wdXRlcg0KYW5kIGFuIGludGVybmV0IGNvbmVjdGlvbiB3aGVuIHlvdSBi
dXkgdGhlIEJhbm5lZCBDRCE8L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxiPjxmb250IGNv
bG9yPSIjMDAwMDk5Ij5MZWFybiBob3cgdG8gdXNlIG9mZnNob3JlIG1vbmV5IGhhdmVucyBh
bmQgYXNzZXQNCnByb3RlY3Rpb24gdHJ1c3RzIHRvIGF2b2lkIGxhd3N1aXRzLCBqdWRnbWVu
dHMsIGFuZCBmb29sIHRoZSBtb3N0IGFnZ3Jlc3NpdmUNCnRheCBjb2xsZWN0b3IhJm5ic3A7
IElmIHlvdXIgbW9uZXkgaXMgc2l0dGluZyBpbiBhIFVTIGJhbmsgYWNjb3VudCwgeW91cg0K
ZnVuZHMgY2FuIGJlIGxldmllZCBvciBmcm96ZW4gY29tcGxldGVseSBhdCBhbnkgdGltZS4m
bmJzcDsgVGhlIFVTIGdvdmVybm1lbnQNCnVzZXMgImNpdmlsIGFzc2V0IGZvcmZlaXR1cmUi
IHRvIHN0ZWFsIGJpbGxpb25zIG9mIGRvbGxhcnMgZWFjaCB5ZWFyIGZyb20NCmhhcmQtd29y
a2luZywgbGF3IGFiaWRpbmcgY2l0aXplbnMuJm5ic3A7IEdldCB5b3VyIG1vbmV5IG91dCBv
ZiB0aGUgY291bnRyeQ0KYmVmb3JlIFVuY2xlIFNhbSBzbmF0Y2hlcyBpdCBhbGwuPC9mb250
PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+RmluZCBvdXQg
d2hlcmUgdG8gYnV5ICJmb3JiaWRkZW4gcHJvZHVjdHMiIG9uDQp0aGUgSW50ZXJuZXQuIEZ1
cnRoZXIgZWxhYm9yYXRpb24gc2hvdWxkIG5vdCBiZSBuZWNlc3Nhcnk7IGp1c3QgdXNlIHlv
dXINCmltYWdpbmF0aW9uLjwvZm9udD48L2I+PC9saT4NCg0KPGxpPg0KPGI+PGZvbnQgY29s
b3I9IiMwMDAwOTkiPkdldCBhIGJldHRlciBqb2IgYnkgcHVyY2hhc2luZyBhIGNvbGxlZ2Ug
ZGVncmVlDQooaW5jbHVkaW5nIGEgUGhkISkgZm9yIGEgdmVyeSBsb3cgZmVlLiBObyBzdHVk
eSByZXF1aXJlZCE8L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxiPjxmb250IGNvbG9yPSIj
MDAwMDk5Ij5JZiB5b3VyIEVYIGlzIGNvbWluZyBhZnRlciB5b3VyIG1vbmV5LCBzdGF5IG9u
ZQ0Kc3RlcCBhaGVhZCBvZiB0aGUgbGF3eWVycyBhbmQga2VlcCB0aGVpciBncmVlZHkgaGFu
ZHMgb2ZmIHlvdXIgbG9vdC4gRmluZA0Kb3V0IGhvdyB0byBoaWRlIHlvdXIgbW9uZXkgd2hl
cmUgaXQgd2lsbCBuZXZlciBiZSBmb3VuZC48L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxi
Pjxmb250IGNvbG9yPSIjMDAwMDk5Ij5Bdm9pZCBsZWdhbCBwcm9ibGVtcywganVkZ21lbnRz
LCBjb252aWN0aW9ucywNCmFuZCBldmVuIHByaXNvbiBzZW50ZW5jZXMgYnkgb2J0YWluaW5n
IGEgY29tcGxldGVseSBuZXcgaWRlbnRpdHkgYW5kIGRpc2FwcGVhcmluZw0Kd2l0aG91dCBh
IHRyYWNlITwvZm9udD48L2I+PC9saT4NCg0KPGxpPg0KPGI+PGZvbnQgY29sb3I9IiMwMDAw
OTkiPkVyYXNlIHlvdXIgY3JpbWluYWwgcmVjb3JkIGFuZCBvYnRhaW4gYSBjb3B5IG9mDQp5
b3VyIEZCSSBmaWxlIHVzaW5nIHRoZSBGcmVlZG9tIG9mIEluZm9ybWF0aW9uIEFjdC4mbmJz
cDsgRmluZCBvdXQgaWYgdGhlDQpnb3Zlcm5tZW50IGlzIGludmVzdGlnYXRpbmcgeW91IE5P
VyBiZWZvcmUgaXQncyB0b28gTEFURSE8L2ZvbnQ+PC9iPjwvbGk+DQo8L3VsPg0KPGZvbnQg
c2l6ZT0rMT5JZiB5b3UgaGF2ZSBiZWVuIHB1dHRpbmcgb2ZmIGJ1eWluZyBUaGUgQmFubmVk
IENELCB3aGF0IGFyZQ0KeW91PC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+d2FpdGluZyBm
b3I/Jm5ic3A7IEJpZyBCcm90aGVyIGlzIGFscmVhZHkgYnJlYXRoaW5nIGRvd24NCm15IG5l
Y2ssIHNvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+SSBjYW4ndCBrZWVwIHNlbGxpbmcg
aXQgZm9yZXZlci4mbmJzcDsgSWYgeW91IGtlZXAgd2FpdGluZw0KdG8gcGxhY2U8L2ZvbnQ+
DQo8YnI+PGZvbnQgc2l6ZT0rMT55b3VyIG9yZGVyLCB5b3UgbWF5IG5ldmVyIGZpbmQgVGhl
IEJhbm5lZCBDRCBhZ2Fpbi4mbmJzcDsNCkZvciBvbmx5PC9mb250Pg0KPGJyPjxmb250IHNp
emU9KzE+JDE5Ljk5LCB5b3Ugd2lsbCBnYWluIHZhbHVhYmxlIHBlYWNlLW9mLW1pbmQga25v
d2luZw0KaG93IHRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+c2FmZWd1YXJkIHlvdXJz
ZWxmLCB5b3VyIGZhbWlseSwgYW5kIHlvdXIgbW9uZXkuJm5ic3A7DQpXaG8gY2FuIHB1dCBh
PC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+cHJpY2Ugb24gZnJlZWRvbT8hPC9mb250Pg0K
PHA+PGk+PHU+PGZvbnQgc2l6ZT0rMT5IZXJlIGlzIGFub3RoZXIgbG9vayBhdCB0aGUgY29u
dGVudHMgb2YgdGhlIEJBTk5FRA0KQ0Q6PC9mb250PjwvdT48L2k+DQo8cD48aW1nIFNSQz0i
aHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3
aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkZpbmQgY29u
ZmlkZW50aWFsIGluZm8gb24gYW55b25lIGluIDMwIG1pbnV0ZXMgb3I8L2ZvbnQ+PC9mb250
Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmxlc3Mgb24gdGhl
IEludGVybmV0LiBZb3UnbGwgYmUNCmFibGUgdG8gdHJhY2sgZG93biB5b3VyPC9mb250Pjwv
Zm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5vbGQgZmxh
bWUsIGZpbmQgb3V0IGhvdyBtdWNoIG1vbmV5DQp5b3VyIGV4IGlzIGhpZGluZzwvZm9udD48
L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+aW4gdGhl
aXIgYmFuayBhY2NvdW50LCBvciBydW4gYQ0KYmFja2dyb3VuZCBjaGVjayBvbjwvZm9udD48
L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+cHJvZXNw
ZWN0aXZlIGNsaWVudCBvciBlbXBsb3llZS4NCkV2ZW4gZ292ZXJubWVudDwvZm9udD48L2Zv
bnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+YWdlbmNpZXMg
aGF2ZSB0cm91YmxlIG9idGFpbmluZw0KbXVjaCBvZiB0aGlzIGluZm9ybWF0aW9uLjwvZm9u
dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+WW91
IHdpbGwgaGF2ZSBhbGwgdGhlIHJlc291cmNlcw0Kb2YgYW55IHByb2Zlc3Npb25hbDwvZm9u
dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+aW52
ZXN0aWdhdG9yIHJpZ2h0IGF0IHlvdXIgZmluZ2VydGlwcw0KLSBvbiB5b3VyIGhvbWU8L2Zv
bnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmNv
bXB1dGVyITwvZm9udD48L2ZvbnQ+DQo8cD48aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVz
YS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xv
cj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkxpc3Qgb2YgY29tcGFuaWVzIHdobyB3aWxs
IGlzc3VlIHlvdSBhIGNvbGxlZ2U8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIj
NjY2NjY2Ij48Zm9udCBzaXplPSsxPmRlZ3JlZSAoaW5jbHVkaW5nIGEgUGhkLikgZm9yIGEN
CmZlZS4gTm8gc3R1ZHkgcmVxdWlyZWQhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJo
dHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdp
ZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KTGVhcm4gaG93
IHRvIGdldCBGUkVFIGNhYmxlIGFuZCBEU1MgY2hhbm5lbHMsPC9mb250PjwvZm9udD4NCjxi
cj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5pbmNsdWRpbmcgdGhlIGFk
dWx0IHN0YXRpb25zIGFuZA0KUGF5LVBlci1WaWV3ITwvZm9udD48L2ZvbnQ+DQo8cD48aW1n
IFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdo
dD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkhv
dyB0byBPYnRhaW4gTWljcm9zb2Z0IFByb2R1Y3RzIGFic29sdXRlbHk8L2ZvbnQ+PC9mb250
Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPkZSRUUsIHRoZSBz
YWZlIGFuZCBMRUdBTCB3YXkhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8v
Y29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5
Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KTGlzdCBvZiBzdXBwbGll
cnMgb2YgInF1ZXN0aW9uYWJsZSIgaXRlbXMsIHN1Y2g8L2ZvbnQ+PC9mb250Pg0KPGJyPjxm
b250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmFzIGZjYyBiYW5uZWQgY29tbXVu
aWNhdGlvbnMgZGV2aWNlcywNCnNjYW5uZXJzLDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQg
Y29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+bmlnaHQgdmlzaW9uIGdvZ2dsZXMsIHBh
c3Nwb3J0cywNCmZha2UgaWRlbnRpZmljYXRpb24sPC9mb250PjwvZm9udD4NCjxicj48Zm9u
dCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5hbmQgZXZlcnl0aGluZyBlbHNlIHRo
YXQgeW91IHdvbid0DQpmaW5kIGluIHRoZSBiYWNrPC9mb250PjwvZm9udD4NCjxicj48Zm9u
dCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5vZiBTb2xkaWVyIG9mIEZvcnR1bmUg
bWFnYXppbmUhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25l
dXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNv
bG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KRmluZCBwcm9kdWN0cyB0byByZXNlbGwg
b24gdGhlIEludGVybmV0IHdpdGggb3VyPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xv
cj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5XaG9sZXNhbGUgRGlyZWN0b3J5IGNvbnRhaW5p
bmcNCm92ZXIgMSBtaWxsaW9uPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2
NjY2NiI+PGZvbnQgc2l6ZT0rMT4odGhhdCdzIHJpZ2h0LCBvbmUgbWlsbGlvbiEpIHdob2xl
c2FsZQ0Kc291cmNlcyBmb3I8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2
NjY2Ij48Zm9udCBzaXplPSsxPmNvbXB1dGVycywgZWxlY3Ryb25pY3MsIGJlYW5pZXMsDQp0
cmVuZCBpdGVtcyw8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48
Zm9udCBzaXplPSsxPmpld2VscnksIGNhcnMsIGNvbGxlY3RpYmxlcywgYW5kDQpldmVyeXRo
aW5nIGVsc2UhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25l
dXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNv
bG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KT3ZlciAyNSBtaWxsaW9uIGVtYWlsIGFk
ZHJlc3NlcywgZnJlc2ggYW5kPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2
NjY2NiI+PGZvbnQgc2l6ZT0rMT50YXJnZXRlZCEgWW91IGNhbiB1c2UgdGhlc2UgdG8NCmNv
bnRhY3QgdGhlIHBlb3BsZTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2
NjYiPjxmb250IHNpemU9KzE+YW5kIHNlbmQgdGhlbSB5b3VyIGFkdmVydGlzZW1lbnRzLjwv
Zm9udD48L2ZvbnQ+DQo8cD48aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1h
Z2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2
NiI+PGZvbnQgc2l6ZT0rMT4NCkZpbmQgb3V0IGhvdyB0byBnZXQgYSBjb21wbGV0ZWx5IG5l
dyBpZGVudGl0eS48L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48
Zm9udCBzaXplPSsxPkRpc2FwcGVhciB3aXRob3V0IGEgdHJhY2UhPC9mb250PjwvZm9udD4N
CjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdp
ZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXpl
PSsxPg0KRmluZCBvdXQgaG93IHRvIEVSQVNFIGJhZCBjcmVkaXQgYW5kIGV2ZW48L2ZvbnQ+
PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmNyZWF0
ZSBhIHdob2xlIG5ldyBmaWxlIGluIHRoZQ0KY3JlZGl0IGJ1cmVhdSBjb21wdXRlcnMuPC9m
b250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFn
ZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2
Ij48Zm9udCBzaXplPSsxPg0KTGVhcm4gaG93IHRvIGJlYXQgdGhlIElSUy4gVGF4IHRpcHMg
Zm9yIHRoZTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250
IHNpemU9KzE+cmVzdCBvZiB1cy48L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6
Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9
MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpDb21wbGV0ZSBndWlk
ZSBvbiBob3cgdG8gY2xhaW0gcHVibGljIGxhbmQ8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250
IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPm9mZmVyZWQgYnkgdGhlIEdvdmVybm1l
bnQuIFlvdQ0KY2FuIGZpbmQgeW91cjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9
IiM2NjY2NjYiPjxmb250IHNpemU9KzE+ZHJlYW0gaG9tZSBmb3IgYSByaWRpY3Vsb3VzbHkg
bG93DQpwcmljZSBvciBidXk8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2
NjY2Ij48Zm9udCBzaXplPSsxPnByb3BlcnRpZXMgdG8gcmVzZWxsIGZvciBhIGh1Z2UNCnBy
b2ZpdCE8L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2Eu
Y29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9MTk+PGZvbnQgY29sb3I9
IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpBY2NlcHQgY2hlY2tzIGZyb20geW91ciBjdXN0
b21lcnMgYnkgZmF4LDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYi
Pjxmb250IHNpemU9KzE+cGhvbmUgYW5kIGVtYWlsIHdpdGggdGhlIGZ1bGwgd29ya2luZw0K
dmVyc2lvbiBvZjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxm
b250IHNpemU9KzE+Q2hlY2tlciBTb2Z0d2FyZSBpbmNsdWRlZCE8L2ZvbnQ+PC9mb250Pg0K
PHA+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lm
IiBoZWlnaHQ9MTkgd2lkdGg9MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9
KzE+DQpCdXNpbmVzcyBzb2Z0d2FyZSB0byBoZWxwIHlvdSBydW4geW91ciBzbWFsbDwvZm9u
dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+YnVz
aW5lc3MsIGluY2x1ZGluZyBsYWJlbCBtYWtlcg0Kc29mdHdhcmUsIG1vbmV5PC9mb250Pjwv
Zm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5tYW5hZ2Vt
ZW50IHNvZnR3YXJlLCBJUlMgZm9yZ2l2ZW5lc3MNCnByb2dyYW0sPC9mb250PjwvZm9udD4N
Cjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5kYXRhYmFzZSBzb2Z0
d2FyZSwgYW5kIG11Y2ggbW9yZS48L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6
Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9
MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpBIGh1Z2UgY29sbGVj
dGlvbiBvZiBzY3JlZW5zYXZlcnMsIGdyYXBoaWNzLDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZv
bnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+Y2xpcGFydCwgYW5kIGRlc2t0b3Ag
dGhlbWVzIHRvDQpzcGljZSB1cCB5b3VyIGNvbXB1dGVyLjwvZm9udD48L2ZvbnQ+DQo8cD48
aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhl
aWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4N
Ck1VQ0gsIE1VQ0ggTU9SRSB0aGF0IHdlIGRvbid0IGhhdmUgcm9vbSB0byBsaXN0ITwvZm9u
dD48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSsxPldlIGFyZSBzbyBjb25maWRlbnQgdGhhdCB5
b3Ugd2lsbCBsb3ZlIHRoaXMgQ0QgdGhhdCB3ZTwvZm9udD4NCjxicj48Zm9udCBzaXplPSsx
Pm9mZmVyIGEgZnVsbCAzMC1kYXksIG5vIHF1ZXN0aW9ucyBhc2tlZCBtb25leS1iYWNrPC9m
b250Pg0KPGJyPjxmb250IHNpemU9KzE+Z3VhcmFudGVlLiBUbyBvcmRlciB0aGUgIkJhbm5l
ZCBDRCIgcmlnaHQgbm93IGZvciB0aGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5zdXBl
ciBsb3cgcHJpY2Ugb2Ygb25seSAkMTkuOTksIGp1c3QgY2xpY2sgb24gdGhlIGxpbms8L2Zv
bnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5iZWxvdyB0byBwYXkgd2l0aCBhIFZpc2Egb3IgTWFz
dGVyY2FyZDo8L2ZvbnQ+DQo8YnI+Jm5ic3A7DQo8dGFibGUgQk9SREVSPTAgQ09MUz0yIFdJ
RFRIPSI1MCUiID4NCjx0cj4NCjx0ZD48Zm9udCBzaXplPSsyPjxhIGhyZWY9Imh0dHA6Ly93
d3cuY29tcHV6b25ldXNhLmNvbS9jY3BheW1lbnQvYmFubmVkY2Q3Mi5odG0iPk9yZGVyDQpO
b3chPC9hPjwvZm9udD48L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxpbWcgU1JDPSJodHRwOi8v
Y29tcHV6b25ldXNhLmNvbS9pbWFnZXMvZ3VhcmFudGVlLmdpZiIgaGVpZ2h0PTk2IHdpZHRo
PTk1PjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KDQo8cD5PciB5b3UgbWF5
IHBheSB3aXRoIGNhc2gsIGNoZWNrIG9yIG1vbmV5IG9yZGVyIGJ5IHByaW50aW5nIHRoZSBv
cmRlcg0KPGJyPmZvcm0gYmVsb3cgYW5kIHNlbmRpbmcgaXQgd2l0aCB5b3VyIHBheW1lbnQu
DQo8cD48Yj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIENVVCBIRVJFIC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tPC9iPg0KPHA+UHJvZHVjdDogIlRoZSBCYW5uZWQgQ0QiDQo8YnI+UHJp
Y2U6ICQxOS45OSArICQ0LjAxIHNoaXBwaW5nL2hhbmRsaW5nDQo8cD5IT1cgVE8gT1JERVIg
QlkgTUFJTDogUHJpbnQgb3V0IHRoaXMgb3JkZXIgZm9ybSBhbmQgc2VuZCBjYXNoLA0KPGJy
PnBlcnNvbmFsIGNoZWNrLCBtb25leSBvcmRlciBvciBjYXNoaWVyJ3MgY2hlY2sgdG8gdGhl
IGFkZHJlc3MgbGlzdGVkDQpiZWxvdzoNCjxwPlF1aWtzaWx2ZXIgRW50ZXJwcmlzZXMgSW5j
Lg0KPGJyPjM3OTIgQnJvYWR3YXkgIzM5OA0KPGJyPk5ldyBZb3JrLCBOWSAxMDAzMg0KPHA+
WW91ciBTaGlwcGluZyBJbmZvcm1hdGlvbjoNCjxwPllvdXIgTmFtZV9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPllvdXIgQWRkcmVzc19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPllvdXIgQ2l0eV9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPlN0YXRl
IC8gWmlwX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJy
PlBob25lICM6IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KPGJyPihGb3IgcHJvYmxlbXMgd2l0aCB5b3VyIG9yZGVyIG9ubHkuIE5vIHNhbGVzbWVu
IHdpbGwgY2FsbC4pDQo8cD5FbWFpbCBBZGRyZXNzX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KPHA+UGxlYXNlIG5vdGUgdGhhdCBtYWlsLWluIG9yZGVycyBt
YXkgYmUgZGVsYXllZCAyLTQgd2Vla3MuDQo8cD5bIF0gSSBhbSBlbmNsb3NpbmcgYSBjaGVj
ayBvciBtb25leSBvcmRlciBmb3IgJDI0LjAwDQo8cD5bIF0gSSBhbSBtYWlsaW5nIG15IGNy
ZWRpdCBjYXJkIG51bWJlci4gKE5vdGUgeW91ciBjYXJkIHdpbGwgYmUgY2hhcmdlZA0KZm9y
ICQyNC4wMCkNCjxwPklmIHBheWluZyBieSBjcmVkaXQgY2FyZCwgcGxlYXNlIGZpbGwgaW4g
dGhlIGluZm9ybWF0aW9uIGJlbG93Og0KPHA+Q3JlZGl0IENhcmQgTnVtYmVyOl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQo8YnI+RXhwaXJhdGlvbiBEYXRlOl9fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KPGJyPlNpZ25hdHVyZTpfX19fX19fX19fX19fX19fX19f
X19fX19fDQo8YnI+RGF0ZTpfX19fX19fX19fX19fX19fX19fXw0KPHA+Tk9URTogVGhpcyBD
RCBpcyBmb3IgaW5mb3JtYXRpb25hbCwgZWR1Y2F0aW9uYWwsIG9yDQo8YnI+ZW50ZXJ0YWlu
bWVudCBwdXJwb3NlcyBvbmx5LiZuYnNwOyBTb21lIG9mIHRoZSBhY3Rpdml0aWVzDQo8YnI+
ZGVzY3JpYmVkIG9uIHRoaXMgQ0QgbWF5IGJlIGlsbGVnYWwgaWYgY2FycmllZCBvdXQuDQo8
YnI+VGhpcyBDRCBjb250YWlucyBsaW5rcyBhbmQgYWRkcmVzc2VzIG9mIGNvbXBhbmllcw0K
PGJyPmFuZCBpbmRpdmlkdWFscyB3aGljaCBwcm9kdWNlIHZhcmlvdXMgcHJvZHVjdHMsIG9y
DQo8YnI+b2ZmZXIgdmFyaW91cyBzZXJ2aWNlcywgd2hpY2ggbWF5IGJlIGlsbGVnYWwgaW4g
eW91cg0KPGJyPmNvdW50cnksIHN0YXRlLCBvciBjaXR5LiZuYnNwOyBIb3dldmVyLCBpdCBp
cyBwZXJmZWN0bHkNCjxicj5MRUdBTCB0byBwdXJjaGFzZSBhbmQgcG9zc2VzcyB0aGUgQmFu
bmVkIENEIGluIHRoZQ0KPGJyPlVuaXRlZCBTdGF0ZXMgb2YgQW1lcmljYS4mbmJzcDsgQ29u
dGFpbnMgYXBwcm94aW1hdGVseQ0KPGJyPjEwMCBtZWdzIG9mIGluZm9ybWF0aW9uLg0KPHA+
U2hpcHBpbmcgb3V0c2lkZSBVU0EgYWRkICQxMC4wMA0KPHA+KioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCjxicj5Zb3UgYXJl
IHJlY2lldmluZyBhbiB1bnNvbGljaXRlZCBjb21tZXJjaWFsIGVtYWlsIGZyb20NCjxicj5R
dWlrc2lsdmVyIEVudGVycHJpc2VzIEluYy4mbmJzcDsgV2UgcmVjb2duaXplIHRoYXQgeW91
IG1heQ0KPGJyPm5vdCB3aXNoIHRvIHJlY2lldmUgc3VjaCBlbWFpbHMgaW4gdGhlIGZ1dHVy
ZSwgYW5kIHdlDQo8YnI+aGF2ZSBwcm92aWRlZCBhIGxpbmsgdG8gYXV0b21hdGljYWxseSBh
bmQgaW5zdGFudGx5DQo8YnI+cmVtb3ZlIHlvdXJzZWxmOiA8YSBocmVmPSJodHRwOi8vd3d3
LmNvbXB1em9uZXVzYS5jb20vcmVtb3ZlLmh0bSI+UkVNT1ZFPC9hPg0KPGJyPlRoaXMgbWVz
c2FnZSBpcyBiZWluZyBzZW50IHRvIHlvdSBpbiBjb21wbGlhbmNlIHdpdGgNCjxicj5mZWRl
cmFsIGd1aWRlbGluZXMgZ292ZXJuaW5nIHRoZSB0cmFuc21pc3Npb24gb2YNCjxicj51bnNv
bGljaXRlZCBjb21tZXJjaWFsIGVtYWlsLCBpbmNsdWRpbmcgdGhlIHByb3Zpc2lvbiBvZg0K
PGJyPmNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIG91ciBjb21wYW55IHdpdGhpbiB0aGlzIGVt
YWlsLCBhDQo8YnI+dmFsaWQgcmV0dXJuIGVtYWlsIGFkZHJlc3MsIGFuZCBhIHdheSBmb3Ig
Y3VzdG9tZXJzDQo8YnI+dG8gcmVtb3ZlIHRoZW1zZWx2ZXMuJm5ic3A7IFBsZWFzZSBub3Rl
LCBob3dldmVyLCB0aGF0IG91cg0KPGJyPmVtYWlsIGFkZHJlc3Mgd2FzIHZhbGlkIGF0IHRo
ZSB0aW1lIG9mIHNlbmRpbmcsIGJ1dCBtYXkNCjxicj5iZSBjYW5jZWxsZWQgYnkgdGhlIElT
UCBzaG9ydGx5IHRoZXJlYWZ0ZXIgZHVlIHRvIG91cg0KPGJyPnVzZSBvZiB1bnNvbGljaXRl
ZCBlbWFpbC4mbmJzcDsgWW91IGNhbiByZWFkIGFib3V0IHRoZSB2YXJpb3VzDQo8YnI+bGF3
cyBnb3Zlcm5pbmcgdW5zb2xpY2l0ZWQgZW1haWw6IGh0dHA6Ly9zcGFtbGF3cy5jb20NCjxi
cj4iVW5zb2xpY2l0ZWQgY29tbWVyY2lhbCBlbGVjdHJvbmljIG1haWwgY2FuIGJlIGFuIGlt
cG9ydGFudA0KPGJyPm1lY2hhbmlzbSB0aHJvdWdoIHdoaWNoIGJ1c2luZXNzZXMgYWR2ZXJ0
aXNlIGFuZCBhdHRyYWN0DQo8YnI+Y3VzdG9tZXJzIGluIHRoZSBvbmxpbmUgZW52aXJvbm1l
bnQuIiZuYnNwOyAtLSBVLlMuIENvbmdyZXNzLA0KPGJyPkguUi4gMTA2dGggQ09OR1JFU1Mg
MmQgU2Vzc2lvbiBILiBSLiAzMTEzIFNlYy4gMiAoYSkzIEp1bHkNCjxicj4xOSwgMjAwMCBo
dHRwOi8vd3d3LnNwYW1sYXdzLmNvbS9mZWRlcmFsL2hyMzExMy5odG1sDQo8YnI+KioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN
Cjxicj4mbmJzcDsNCjxicj4mbmJzcDsNCjwvYm9keT4NCjwvaHRtbD4NCg==

------=_NextPart_000_001__2979830_44280.05--




From owner-aaa-bof@merit.edu  Tue Jan 30 10:32:50 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10512
	for <aaa-archive@odin.ietf.org>; Tue, 30 Jan 2001 10:32:49 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 650EF5DEAE; Tue, 30 Jan 2001 10:31:17 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 4E9BF5DF0E; Tue, 30 Jan 2001 10:31:17 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 024975DEAE
	for <aaa-wg@merit.edu>; Tue, 30 Jan 2001 10:31:16 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA21159;
	Tue, 30 Jan 2001 07:31:13 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16136;
	Tue, 30 Jan 2001 07:31:08 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA02155;
	Tue, 30 Jan 2001 07:31:06 -0800 (PST)
Date: Tue, 30 Jan 2001 07:31:06 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: [AAA-WG]: DIAMETER or Diameter?
To: aaa-wg@merit.edu, diameter@diameter.org
Message-ID: <Roam.SIMC.2.0.6.980868666.23805.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

All,

One of my co-authors correctly pointed out that the use of all CAPS is
innapropriate, since DIAMETER is not an acronym, and recommended that it be
changed to Diameter. I am asking for WG concensus on this one, although I do
tend to agree.

Objections?

PatC




From owner-aaa-bof@merit.edu  Tue Jan 30 10:51:48 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11046
	for <aaa-archive@odin.ietf.org>; Tue, 30 Jan 2001 10:51:48 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 797115DE10; Tue, 30 Jan 2001 10:51:25 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 651B55DE5B; Tue, 30 Jan 2001 10:51:25 -0500 (EST)
Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110])
	by segue.merit.edu (Postfix) with ESMTP id 82D3A5DE10
	for <aaa-wg@merit.edu>; Tue, 30 Jan 2001 10:51:24 -0500 (EST)
Received: from Interlinknetworks.com (hst37155.phys.uu.nl [131.211.37.155])
	by aaa.interlinknetworks.com (Postfix) with ESMTP
	id 724A272; Tue, 30 Jan 2001 10:51:33 -0500 (EST)
Message-ID: <3A76E2F4.97CFD75D@Interlinknetworks.com>
Date: Tue, 30 Jan 2001 16:51:16 +0100
From: David Spence <DSpence@Interlinknetworks.com>
Organization: Interlink Networks, Inc.
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Cc: aaa-wg@merit.edu, diameter@diameter.org
Subject: Re: [AAA-WG]: DIAMETER or Diameter?
References: <Roam.SIMC.2.0.6.980868666.23805.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I prefer Diameter.  I don't particularly like all caps and am not
particularly impressed by strained acronyms.  So please don't rename it
"Diameter Is Aaa Messaging Explained Twice as Eloquently as Radius" just so
you can write it all in caps as DIAMETER.

Patrice Calhoun wrote:
> 
> All,
> 
> One of my co-authors correctly pointed out that the use of all CAPS is
> innapropriate, since DIAMETER is not an acronym, and recommended that it be
> changed to Diameter. I am asking for WG concensus on this one, although I do
> tend to agree.
> 
> Objections?
> 
> PatC

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



From owner-aaa-bof@merit.edu  Tue Jan 30 10:52:52 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11100
	for <aaa-archive@odin.ietf.org>; Tue, 30 Jan 2001 10:52:52 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 864005DE75; Tue, 30 Jan 2001 10:52:34 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 745945DE73; Tue, 30 Jan 2001 10:52:34 -0500 (EST)
Received: from lint.cisco.com (lint.cisco.com [171.68.224.209])
	by segue.merit.edu (Postfix) with ESMTP id 253AB5DE5B
	for <aaa-wg@merit.edu>; Tue, 30 Jan 2001 10:52:33 -0500 (EST)
Received: from knox6195.CISCO.COM (rsargent@knox6195.cisco.com [161.44.216.195]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA29029; Tue, 30 Jan 2001 07:52:25 -0800 (PST)
Date: Tue, 30 Jan 2001 10:52:22 -0500
From: Robert Sargent <RSargent@cisco.com>
To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Cc: aaa-wg@merit.edu, diameter@diameter.org
Subject: Re: [AAA-WG]: DIAMETER or Diameter?
Message-ID: <20010130105222.C8219@Cisco.COM>
Reply-To: Robert Sargent <RSargent@cisco.com>
References: <Roam.SIMC.2.0.6.980868666.23805.pcalhoun@nasnfs>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Roam.SIMC.2.0.6.980868666.23805.pcalhoun@nasnfs>; from pcalhoun@nasnfs.eng.sun.com on Tue, Jan 30, 2001 at 07:31:06AM -0800
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

On Tue, Jan 30, 2001 at 07:31:06AM -0800, Patrice Calhoun promised:
> All,
> 
> One of my co-authors correctly pointed out that the use of all CAPS is
> innapropriate, since DIAMETER is not an acronym, and recommended that it be
> changed to Diameter. I am asking for WG concensus on this one, although I do
> tend to agree.

Agree.

> Objections?

Nope.

-- 
Rob Sargent



From owner-aaa-bof@merit.edu  Tue Jan 30 11:10:14 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11460
	for <aaa-archive@odin.ietf.org>; Tue, 30 Jan 2001 11:10:14 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id B02155DE73; Tue, 30 Jan 2001 11:09:57 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A0AB45DE1B; Tue, 30 Jan 2001 11:09:57 -0500 (EST)
Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44])
	by segue.merit.edu (Postfix) with ESMTP id 324C95DDE1
	for <aaa-wg@merit.edu>; Tue, 30 Jan 2001 11:09:56 -0500 (EST)
Received: (from barney@localhost)
	by mx.databus.com (8.11.1/8.11.1) id f0UG9kM54927;
	Tue, 30 Jan 2001 11:09:46 -0500 (EST)
	(envelope-from barney)
Date: Tue, 30 Jan 2001 11:09:46 -0500
From: Barney Wolff <barney@databus.com>
To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Cc: aaa-wg@merit.edu, diameter@diameter.org
Subject: Re: [AAA-WG]: DIAMETER or Diameter?
Message-ID: <20010130110946.A54824@mx.databus.com>
References: <Roam.SIMC.2.0.6.980868666.23805.pcalhoun@nasnfs>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Roam.SIMC.2.0.6.980868666.23805.pcalhoun@nasnfs>; from pcalhoun@nasnfs.eng.sun.com on Tue, Jan 30, 2001 at 07:31:06AM -0800
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Dial
In
Access
Management
Essentially
Transport-
Enhanced
RADIUS

I'll point out that UNIX is not an acronym either, but is
correctly written with all caps.

If we're down at this level we must be done, right?
:)
Barney

On Tue, Jan 30, 2001 at 07:31:06AM -0800, Patrice Calhoun wrote:
> All,
> 
> One of my co-authors correctly pointed out that the use of all CAPS is
> innapropriate, since DIAMETER is not an acronym, and recommended that it be
> changed to Diameter. I am asking for WG concensus on this one, although I do
> tend to agree.
> 
> Objections?
> 
> PatC
> 
> 



From owner-aaa-bof@merit.edu  Tue Jan 30 12:36:03 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13681
	for <aaa-archive@odin.ietf.org>; Tue, 30 Jan 2001 12:36:03 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 35B105DE1B; Tue, 30 Jan 2001 12:35:47 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 16FD05DDE1; Tue, 30 Jan 2001 12:35:47 -0500 (EST)
Received: from web1.merit.edu (web1.merit.edu [198.108.62.192])
	by segue.merit.edu (Postfix) with ESMTP
	id E187B5DDD7; Tue, 30 Jan 2001 12:35:45 -0500 (EST)
Received: (from web@localhost)
	by web1.merit.edu (8.9.3/8.9.1) id MAA25580;
	Tue, 30 Jan 2001 12:35:45 -0500 (EST)
Date: Tue, 30 Jan 2001 12:35:45 -0500
From: William Bulley <web@merit.edu>
To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Cc: diameter@diameter.org, aaa-wg@merit.edu
Subject: Re: [AAA-WG]: DIAMETER or Diameter?
Message-ID: <20010130123545.I25133@web1.merit.edu>
Mail-Followup-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
	diameter@diameter.org, aaa-wg@merit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1us
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

According to Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>:
> 
> One of my co-authors correctly pointed out that the use of all CAPS is
> innapropriate, since DIAMETER is not an acronym, and recommended that it be
> changed to Diameter. I am asking for WG concensus on this one, although I do
> tend to agree.

Then shall we take this opportunity to make it into an acronym
befitting its heritage?  Afterall, RADIUS was an acronym.  I
have suggested such an acronym to you in the recent past...

Regards,

web...

-- 
William Bulley                     Manager of Software Engineering
Merit Network, Inc.                Email: web@merit.edu
Building One, Suite 2000           Phone: (734) 764-9430
4251 Plymouth Road                 Fax:   (734) 647-3185
Ann Arbor, Michigan  48105-2785

"We're not C++ programmers.  There is one program written in C++
in OpenBSD, out of 300 megabytes of source code." - Theo deRaadt,
father and principal archtitect of the OpenBSD operating system.



From owner-aaa-bof@merit.edu  Tue Jan 30 12:40:16 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13802
	for <aaa-archive@odin.ietf.org>; Tue, 30 Jan 2001 12:40:15 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id D3D4B5DE5D; Tue, 30 Jan 2001 12:39:55 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id C23EE5DDE1; Tue, 30 Jan 2001 12:39:55 -0500 (EST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP
	id 6FDCF5DDD7; Tue, 30 Jan 2001 12:39:54 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA19728;
	Tue, 30 Jan 2001 09:39:52 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28023;
	Tue, 30 Jan 2001 09:39:50 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA04542;
	Tue, 30 Jan 2001 09:39:48 -0800 (PST)
Date: Tue, 30 Jan 2001 09:39:49 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: Re: [AAA-WG]: DIAMETER or Diameter?
To: William Bulley <web@merit.edu>
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>, diameter@diameter.org,
        aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <20010130123545.I25133@web1.merit.edu>
Message-ID: <Roam.SIMC.2.0.6.980876389.9114.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> > One of my co-authors correctly pointed out that the use of all CAPS is
> > innapropriate, since DIAMETER is not an acronym, and recommended that it be
> > changed to Diameter. I am asking for WG concensus on this one, although I do
> > tend to agree.
> 
> Then shall we take this opportunity to make it into an acronym
> befitting its heritage?  Afterall, RADIUS was an acronym.  I
> have suggested such an acronym to you in the recent past...

Well, we could, but it really seems pointless at this time, given that it's
been around for so long.

My favorite is really "Diameter Is Aaa Messaging Explained Twice as Eloquently
as Radius" :)

Barney states:

"If we're down at this level we must be done, right?"

Not really, but I want the document right before it becomes a WG document.

PatC




From owner-aaa-bof@merit.edu  Tue Jan 30 13:05:37 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14400
	for <aaa-archive@odin.ietf.org>; Tue, 30 Jan 2001 13:05:36 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id B1A725DF7C; Tue, 30 Jan 2001 13:01:52 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 954ED5DF7B; Tue, 30 Jan 2001 13:01:52 -0500 (EST)
Received: from web1.merit.edu (web1.merit.edu [198.108.62.192])
	by segue.merit.edu (Postfix) with ESMTP
	id 631B95DF73; Tue, 30 Jan 2001 13:01:50 -0500 (EST)
Received: (from web@localhost)
	by web1.merit.edu (8.9.3/8.9.1) id NAA25720;
	Tue, 30 Jan 2001 13:01:50 -0500 (EST)
Date: Tue, 30 Jan 2001 13:01:50 -0500
From: William Bulley <web@merit.edu>
To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Cc: diameter@diameter.org, aaa-wg@merit.edu
Subject: Re: [AAA-WG]: DIAMETER or Diameter?
Message-ID: <20010130130150.N25133@web1.merit.edu>
Mail-Followup-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
	diameter@diameter.org, aaa-wg@merit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1us
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

According to Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>:
> 
> Well, we could, but it really seems pointless at this time, given that it's
> been around for so long.

What is the "it" that has "been around for so long"?

> My favorite is really "Diameter Is Aaa Messaging Explained Twice as Eloquently
> as Radius" :)

Not bad -- and neither was the other (Barney's?) suggestion...  :-)

Regards,

web...

-- 
William Bulley                     Manager of Software Engineering
Merit Network, Inc.                Email: web@merit.edu
Building One, Suite 2000           Phone: (734) 764-9430
4251 Plymouth Road                 Fax:   (734) 647-3185
Ann Arbor, Michigan  48105-2785

"We're not C++ programmers.  There is one program written in C++
in OpenBSD, out of 300 megabytes of source code." - Theo deRaadt,
father and principal archtitect of the OpenBSD operating system.



From owner-aaa-bof@merit.edu  Tue Jan 30 13:08:11 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14531
	for <aaa-archive@odin.ietf.org>; Tue, 30 Jan 2001 13:08:11 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 3C3B85DF50; Tue, 30 Jan 2001 13:05:42 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 297B75DED9; Tue, 30 Jan 2001 13:05:42 -0500 (EST)
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by segue.merit.edu (Postfix) with SMTP id 37C875DEAC
	for <aaa-wg@merit.edu>; Tue, 30 Jan 2001 13:05:40 -0500 (EST)
Received: (qmail 7673 invoked by uid 500); 30 Jan 2001 18:39:48 -0000
Date: Tue, 30 Jan 2001 12:39:48 -0600
From: David Frascone <dave@frascone.com>
To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Cc: aaa-wg@merit.edu, diameter@diameter.org
Subject: Re: [AAA-WG]: DIAMETER or Diameter?
Message-ID: <20010130123948.A7556@newman.frascone.com>
Mail-Followup-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
	aaa-wg@merit.edu, diameter@diameter.org
References: <Roam.SIMC.2.0.6.980868666.23805.pcalhoun@nasnfs>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Roam.SIMC.2.0.6.980868666.23805.pcalhoun@nasnfs>; from pcalhoun@nasnfs.eng.sun.com on Tue, Jan 30, 2001 at 07:31:06AM -0800
X-encrypt-payload: no
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Shouldn't we just come up with what it stands for instead?  

Distributed Internet Authentication Mechanism Effecting the Total Elimination
of RADIUS

On Tue, Jan 30, 2001 at 07:31:06AM -0800, Patrice Calhoun wrote:
> All,
> 
> One of my co-authors correctly pointed out that the use of all CAPS is
> innapropriate, since DIAMETER is not an acronym, and recommended that it be
> changed to Diameter. I am asking for WG concensus on this one, although I do
> tend to agree.
> 
> Objections?
> 
> PatC
> 
> 



From owner-aaa-bof@merit.edu  Tue Jan 30 13:49:27 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15312
	for <aaa-archive@odin.ietf.org>; Tue, 30 Jan 2001 13:49:27 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id ABAE25DF12; Tue, 30 Jan 2001 13:47:55 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 98FAC5DF0D; Tue, 30 Jan 2001 13:47:55 -0500 (EST)
Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130])
	by segue.merit.edu (Postfix) with ESMTP id 7A2105DEE1
	for <aaa-wg@merit.edu>; Tue, 30 Jan 2001 13:47:53 -0500 (EST)
Received: (from mail@localhost)
	by ahab.tic.siemens.ca (8.9.3/8.9.3) id NAA17381;
	Tue, 30 Jan 2001 13:47:41 -0500 (EST)
Received: from unknown(0.0.0.0) by ahab via smap (V2.1)
	id xma017379; Tue, 30 Jan 01 13:47:15 -0500
Received: (from mail@localhost)
	by mailman.innovation.siemens.ca (8.9.3/8.9.3) id NAA06475;
	Tue, 30 Jan 2001 13:47:14 -0500 (EST)
Received: from ticsmtp2.innovation.siemens.ca(172.21.24.160) by mailman.innovation.siemens.ca via smap (V2.1)
	id xma006367; Tue, 30 Jan 01 13:46:02 -0500
Received: by ticsmtp2.innovation.siemens.ca with Internet Mail Service (5.5.2650.21)
	id <DG4LLTQ7>; Tue, 30 Jan 2001 13:43:52 -0500
Message-ID: <53D69AD06EFAD311842300A0C99B4F08D50C4B@ticsmtp2.innovation.siemens.ca>
From: Arek Nowakowski <Arek.Nowakowski@tic.siemens.ca>
To: "'David Frascone'" <dave@frascone.com>,
        Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: aaa-wg@merit.edu, diameter@diameter.org
Subject: RE: [diameter] Re: [AAA-WG]: DIAMETER or Diameter?
Date: Tue, 30 Jan 2001 13:43:51 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

What about:
Distributed Internet Authentication Mechanism Effectivly and Totaly
Eliminating Radius  ???

Arek Nowakowski

-----Original Message-----
From: David Frascone [mailto:dave@frascone.com]
Sent: Tuesday, January 30, 2001 1:40 PM
To: Patrice Calhoun
Cc: aaa-wg@merit.edu; diameter@diameter.org
Subject: [diameter] Re: [AAA-WG]: DIAMETER or Diameter?


Shouldn't we just come up with what it stands for instead?  

Distributed Internet Authentication Mechanism Effecting the Total
Elimination
of RADIUS

On Tue, Jan 30, 2001 at 07:31:06AM -0800, Patrice Calhoun wrote:
> All,
> 
> One of my co-authors correctly pointed out that the use of all CAPS is
> innapropriate, since DIAMETER is not an acronym, and recommended that it
be
> changed to Diameter. I am asking for WG concensus on this one, although I
do
> tend to agree.
> 
> Objections?
> 
> PatC
> 
> 



From owner-aaa-bof@merit.edu  Tue Jan 30 13:56:27 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15444
	for <aaa-archive@odin.ietf.org>; Tue, 30 Jan 2001 13:56:27 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id AB5195DE23; Tue, 30 Jan 2001 13:56:08 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 99B8D5DDE1; Tue, 30 Jan 2001 13:56:08 -0500 (EST)
Received: from lint.cisco.com (lint.cisco.com [171.68.224.209])
	by segue.merit.edu (Postfix) with ESMTP id 408605DDD7
	for <aaa-wg@merit.edu>; Tue, 30 Jan 2001 13:56:07 -0500 (EST)
Received: from knox6195.CISCO.COM (rsargent@knox6195.cisco.com [161.44.216.195]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA06845; Tue, 30 Jan 2001 10:56:00 -0800 (PST)
Date: Tue, 30 Jan 2001 13:55:57 -0500
From: Robert Sargent <RSargent@cisco.com>
To: Arek Nowakowski <Arek.Nowakowski@tic.siemens.ca>
Cc: "'David Frascone'" <dave@frascone.com>,
        Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>, aaa-wg@merit.edu,
        diameter@diameter.org
Subject: Re: [diameter] Re: [AAA-WG]: DIAMETER or Diameter?
Message-ID: <20010130135557.N8219@Cisco.COM>
Reply-To: Robert Sargent <RSargent@cisco.com>
References: <53D69AD06EFAD311842300A0C99B4F08D50C4B@ticsmtp2.innovation.siemens.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <53D69AD06EFAD311842300A0C99B4F08D50C4B@ticsmtp2.innovation.siemens.ca>; from Arek.Nowakowski@tic.siemens.ca on Tue, Jan 30, 2001 at 01:43:51PM -0500
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Dreamers In Another Megacosm Erroneously Thinking about Eliminating RADIUS.

Okay, back to real work...
Rob

On Tue, Jan 30, 2001 at 01:43:51PM -0500, Arek Nowakowski promised:
> What about:
> Distributed Internet Authentication Mechanism Effectivly and Totaly
> Eliminating Radius  ???
> 
> Arek Nowakowski
> 
> -----Original Message-----
> From: David Frascone [mailto:dave@frascone.com]
> Sent: Tuesday, January 30, 2001 1:40 PM
> To: Patrice Calhoun
> Cc: aaa-wg@merit.edu; diameter@diameter.org
> Subject: [diameter] Re: [AAA-WG]: DIAMETER or Diameter?
> 
> 
> Shouldn't we just come up with what it stands for instead?  
> 
> Distributed Internet Authentication Mechanism Effecting the Total
> Elimination
> of RADIUS
> 
> On Tue, Jan 30, 2001 at 07:31:06AM -0800, Patrice Calhoun wrote:
> > All,
> > 
> > One of my co-authors correctly pointed out that the use of all CAPS is
> > innapropriate, since DIAMETER is not an acronym, and recommended that it
> be
> > changed to Diameter. I am asking for WG concensus on this one, although I
> do
> > tend to agree.
> > 
> > Objections?
> > 
> > PatC
> > 
> > 

-- 
Rob Sargent
Tel: (865) 671-8823
Software Development Manager -*-  Remote Site Manager - Knoxville
10850 Murdock Dr
Knoxville TN 37932                       http://darien.cisco.com/



From owner-aaa-bof@merit.edu  Wed Jan 31 15:01:18 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24893
	for <aaa-archive@odin.ietf.org>; Wed, 31 Jan 2001 15:01:18 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 7B9CE5DF00; Wed, 31 Jan 2001 14:57:50 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 5CEBD5DEE1; Wed, 31 Jan 2001 14:57:50 -0500 (EST)
Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210])
	by segue.merit.edu (Postfix) with ESMTP id EB74D5DE91
	for <aaa-wg@merit.edu>; Wed, 31 Jan 2001 14:57:47 -0500 (EST)
Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id LAA15457; Wed, 31 Jan 2001 11:57:28 -0800 (PST)
Message-Id: <4.1.20010131145349.00a1d180@diablo.cisco.com>
X-Sender: jschnizl@diablo.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 31 Jan 2001 14:56:43 -0500
To: Barney Wolff <barney@databus.com>,
        Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
From: John Schnizlein <jschnizl@cisco.com>
Subject: Re: [AAA-WG]: DIAMETER or Diameter?
Cc: aaa-wg@merit.edu, diameter@diameter.org
In-Reply-To: <20010130110946.A54824@mx.databus.com>
References: <Roam.SIMC.2.0.6.980868666.23805.pcalhoun@nasnfs>
 <Roam.SIMC.2.0.6.980868666.23805.pcalhoun@nasnfs>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

At 11:09 AM 01/30/2001 -0500, Barney Wolff wrote:
>Dial
>In
>Access
>Management
>Essentially
>Transport-
>Enhanced
>RADIUS

Why strain to create an acronym where none existed?
Punning is a fine tradition in naming.
Diameter is twice 'RADIUS'.

>I'll point out that UNIX is not an acronym either, 
>but is correctly written with all caps.

No, Unix is not correctly written with all caps.
"Unix" is a pun on Multics.
Please do not attempt to force an acronym onto "Unix".

John



From owner-aaa-bof@merit.edu  Wed Jan 31 16:19:10 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25836
	for <aaa-archive@odin.ietf.org>; Wed, 31 Jan 2001 16:19:10 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 341B55DFB4; Wed, 31 Jan 2001 16:16:41 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 1DEF55DFBC; Wed, 31 Jan 2001 16:16:41 -0500 (EST)
Received: from cisco.com (titans.cisco.com [161.44.216.10])
	by segue.merit.edu (Postfix) with ESMTP id 5F2A05DFB4
	for <aaa-wg@merit.edu>; Wed, 31 Jan 2001 16:16:38 -0500 (EST)
Received: from knox6046.cisco.com (root@knox6046.cisco.com [161.44.216.46])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA03820;
	Wed, 31 Jan 2001 16:15:38 -0500 (EST)
Received: (from srich@localhost)
	by knox6046.cisco.com (8.11.0/8.11.0) id f0VLFZB09945;
	Wed, 31 Jan 2001 16:15:35 -0500
From: Steve Rich <srich@knox6046.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14968.32887.533758.726464@knox6046.cisco.com>
Date: Wed, 31 Jan 2001 16:15:35 -0500
To: John Schnizlein <jschnizl@cisco.com>
Cc: Barney Wolff <barney@databus.com>,
        Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>, aaa-wg@merit.edu,
        diameter@diameter.org
Subject: Re: [AAA-WG]: DIAMETER or Diameter?
In-Reply-To: <4.1.20010131145349.00a1d180@diablo.cisco.com>
References: <Roam.SIMC.2.0.6.980868666.23805.pcalhoun@nasnfs>
	<4.1.20010131145349.00a1d180@diablo.cisco.com>
X-Mailer: VM 6.90 under Emacs 20.7.1
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


John Schnizlein writes:
 > At 11:09 AM 01/30/2001 -0500, Barney Wolff wrote:
 > >Dial
 > >In
 > >Access
 > >Management
 > >Essentially
 > >Transport-
 > >Enhanced
 > >RADIUS
 > 
 > Why strain to create an acronym where none existed?
 > Punning is a fine tradition in naming.
 > Diameter is twice 'RADIUS'.
 > 
 > >I'll point out that UNIX is not an acronym either, 
 > >but is correctly written with all caps.
 > 
 > No, Unix is not correctly written with all caps.
 > "Unix" is a pun on Multics.
 > Please do not attempt to force an acronym onto "Unix".

Yeah, but MULTICS *is* an acronym.  (I believe that that's why the pun
``UNIX'' is spelled in all-caps, even though it is *not* an
acronym. Sorta hightens the mystique. :)

:)
sjr

 > 
 > John
 > 



From owner-aaa-bof@merit.edu  Wed Jan 31 18:19:50 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27761
	for <aaa-archive@odin.ietf.org>; Wed, 31 Jan 2001 18:19:50 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id 577505DE91; Wed, 31 Jan 2001 18:16:00 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 37BDF5DEB9; Wed, 31 Jan 2001 18:16:00 -0500 (EST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 0728B5DE91
	for <aaa-wg@merit.edu>; Wed, 31 Jan 2001 18:15:58 -0500 (EST)
Received: from purol.East.Sun.COM ([129.148.9.11])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01300;
	Wed, 31 Jan 2001 15:15:57 -0800 (PST)
Received: from onion.east.sun.com (onion [129.148.174.110])
	by purol.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id SAA26990;
	Wed, 31 Jan 2001 18:15:56 -0500 (EST)
Date: Wed, 31 Jan 2001 18:15:54 -0500 (EST)
From: Steven Glass - Solaris Software <Steven.Glass@east.sun.com>
Reply-To: Steven Glass - Solaris Software <Steven.Glass@east.sun.com>
Subject: Re: [AAA-WG]: DIAMETER or Diameter?
To: diameter@diameter.org
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>, aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <14968.32887.533758.726464@knox6046.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.980982954.3744.glass@purol.east>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> 
> John Schnizlein writes:
>  > At 11:09 AM 01/30/2001 -0500, Barney Wolff wrote:
>  > >Dial
>  > >In
>  > >Access
>  > >Management
>  > >Essentially
>  > >Transport-
>  > >Enhanced
>  > >RADIUS

    Diameter's not just for dial-in anymore.  

    Either we figure out some acronym quickly and use "DIAMETER", or we don't
worry about it and use "Diameter".

    My suggestions:

    Diverse
   [Internet]
    Access
    Management using
    Extensible
    Types and
    Enhancements to
    RADIUS

    Diverse 
    Internet 
    Access 
    Management using 
    Extensible 
    Types and
    Enhanced [or element]
    Retrieval

    Diverse [Direct]
    Internet
    Access 
    Management using 
    Extensible
    Types and [/with]
    External [or Efficient or Enhanced]
    Relaying

    mix/match, tweek, etc.  You get where I'm trying to go.  Could use End2End
in there too (if we want to open this up to controversy)...

                              Cheers,
                                  Steve






From owner-aaa-bof@merit.edu  Wed Jan 31 23:04:20 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04661
	for <aaa-archive@odin.ietf.org>; Wed, 31 Jan 2001 23:04:19 -0500 (EST)
Received: by segue.merit.edu (Postfix)
	id ABDD85DEB2; Wed, 31 Jan 2001 23:01:56 -0500 (EST)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 97E665DEE5; Wed, 31 Jan 2001 23:01:56 -0500 (EST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by segue.merit.edu (Postfix) with ESMTP id 38F885DEB2
	for <aaa-wg@merit.edu>; Wed, 31 Jan 2001 23:01:55 -0500 (EST)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id UAA13349;
	Wed, 31 Jan 2001 20:02:09 -0800 (PST)
From: jewelers@building.com
Received: from proxy3.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f1141xm14987;
	Wed, 31 Jan 2001 20:01:59 -0800 (PST)
Received: from gw.pfpfinancial.com.au (pfpfinancial.com.au [203.59.136.86])
	by proxy3.cisco.com (8.11.2/8.11.2) with ESMTP id f1141lu01830;
	Wed, 31 Jan 2001 20:01:48 -0800 (PST)
Received: from 203.59.136.86 (03-118.044.popsite.net [64.24.247.118])
	by gw.pfpfinancial.com.au (8.8.5/8.8.5) with SMTP id LAA29978;
	Thu, 1 Feb 2001 11:50:13 +0800
Message-Id: <200102010350.LAA29978@gw.pfpfinancial.com.au>
Date: Wed, 31 Jan 01 21:08:00 EST
To: g411hjd8h@idnkjkwo0.com
Subject: [AAA-WG]: Worth a Shot
Sender: owner-aaa-bof@merit.edu
Precedence: bulk



                                   The Program

                        
-------------------------------------------------------------------------------------------------------
AS SEEN ON NATIONAL TV --- INCREDIBLE $0 to $50,000 in
90 days!!! 
-------------------------------------------------------------------------------------------------------

You can earn $50,000 or more in next the 90 days
sending e-mail. Seem impossible? Read on for details.

This is the letter you've been
reading about in the news lately.  Due to the popularity of this
letter on the Internet, a major nightly news program recently devoted
an entire show to the investigation of the program described below to
see if it really can make people money.

The show also investigated whether or not the program was legal.
Their findings proved once and for all that there are absolutely no
laws prohibiting the participation in the program. This has helped
to show people that this is a simple, harmless and fun way to make
some extra money at home.

The results of this show have been truly remarkable. So many people
are participating that those involved are doing much better than ever
before.  Since everyone makes more as more people try it out, its
been very exciting to be a part of lately. You will understand once you
experience it.

                              HERE IT IS BELOW:

                 *** Print This Now For Future Reference ***

The following income opportunity is one you may be interested in
taking a look at. It can be started with VERY LITTLE investment and
the income return is TREMENDOUS!!!

               $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
            If you would like to make at least $50,000 in less than 90 days !
            Please read the enclosed program...THEN READ IT AGAIN!!!
               $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY.It does
not require you to come into contact with people, do any hard work,
and best of all, you never have to leave the house except to get the
mail. If you believe that someday you'll get that big break that you
'vebeen waiting for, THIS IS IT!  Simply follow the instructions,
andyour dreams will come true. This multi-level e-mail order
marketingprogram works perfectly...100% EVERY TIME.

E-mail is the sales tool of the future. Take advantage of this
non-commercialized method of advertising NOW!!! The longer you
wait, the more people will be doing business using e-mail. Get
your piece of this action!!!

MULTI-LEVEL MARKETING (MLM) has finally gained respectability.
It is being taught in the Harvard Business School, and both Stanford
Research and the Wall Street Journal have stated that between 50%
and 65% of all goods and services will be sold through multi-level
methods by the mid to late 1990's.  This is a Multi-Billion Dollar
industry and of the 500,000 millionaires in the U.S., 20% (100,000)
made their fortune in the last several years in MLM.  Moreover,
statistics show 45 people become millionaires everyday through
Multi-Level Marketing.

You may have heard this story before, but over the summer Donald
Trump made an appearance on the David Letterman show. Dave asked
him what he would do if he lost everything and had to start over from
scratch. Without hesitating, Trump said he would find a good network
marketing company and get to work. The audience started to hoot and
boo him. He looked out at the audience and dead-panned his response:
"That's why I'm sitting up here and you are all sitting out there!"

The enclosed information is something I almost let slip through my
fingers. Fortunately, sometime later I re-read everything and gave
somethought and study to it. My name is Johnathon Rourke. Two years
ago, the corporation I worked at for the past twelve years down-sized and my
position was eliminated. After unproductive job interviews, I decided
to open my own business. Over the past year, I incurred many
unforeseen financial problems.  I owed my family, friends and
creditors over $35,000.
The economy was taking a toll on my business and I just couldn't seem
to make ends meet. I had to refinance and borrow against my home to
support my family and struggling business. AT THAT MOMENT something
significant happened in my life and I am writing to share the
experience in hopes that this will change your life FOREVER
FINANCIALLY!!!

In mid December, I received this program via e-mail. Six month's
prior to receiving this program I had been sending away for
information on various business opportunities. All of the programs I
received, in my opinion, were not cost effective. They were either
too difficult for me to comprehend or the initial investment was too much 
for me to risk to see if they would work or not. One claimed that I would 
make a million dollars in one year...it didn't tell me I'd have to write a
 book to make it!

But like I was saying, in December of 1997 I received this program. I
didn't send for it, or ask for it, they just got my name off a
mailing list.THANK GOODNESS FOR THAT!!! After reading it several times, to make
sure I was reading it correctly, I couldn't believe my eyes. Here was a MONEY
MAKING PHENOMENON. I could invest as much as I wanted to start,
without putting me further into debt. After I got a pencil and paper
and figured it out, I would at least get my money back. But like most
of you I was still a little skeptical and a little worried about the
legal aspects of it all. So I checked it out with the U.S. Post Office 
 (1-800-725-2161 24-hrs) and they confirmed that it is indeed legal! After 
 determining the program was LEGAL and NOT A CHAIN LETTER, I decided
 "WHY NOT."

Initially I sent out 10,000 e-mails. It cost me about $15 for my time
on-line. The great thing about e-mail is that I don't need any money
for printing to send out the program, and because all of my orders
are fulfilled via e-mail, my only expense is my time. I am telling
you like it is I hope it doesn't turn you off, but I promised myself that I would not
"rip-off" anyone, no matter how much money it made me.

In less than one week, I was starting to receive orders for REPORT #1
By January 13, I had received 26 orders for REPORT #1. Your goal is to
"RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF 
YOU DON'T, SEND OUT MORE PROGRAMS UNTIL YOU DO!" My first 
step in making $50,000 in 90 days was done.  By January 30, I had received
196 orders for REPORT #2. Your goal is to "RECEIVE AT LEAST 100+ ORDERS
FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE PROGRAMS 
UNTIL YOU DO. ONCE YOU HAVE 100 ORDERS,
THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL." Well, I
had 196 orders for REPORT #2, 96 more than I needed. So I sat back
and relaxed. By March 1, of my e-mailing of 10,000, I received $58,000 with
 more coming in every day.

I paid off ALL my debts and bought a much needed new car. Please take
time to read the attached program, IT WILL CHANGE YOUR LIFE FOREVER!!
! Remember, it won't work if you don't try it. This program does work
, but you must follow it EXACTLY! Especially the rules of not trying
to place your name in a different place. It won't work and you'll
lose out on a lot of money!
In order for this program to work, you must meet your goal of 20+
orders for REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000
 or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!!

If you choose not to participate in this program, I am sorry. It
really is a great opportunity with little cost or risk to you. If you
choose to participate, follow the program and you will be on your way
to financial security. If you are a fellow business owner and are in
financial trouble like I was, or you want to start your own business, consider 
this a sign. I DID!

                                 Sincerely,
                              Johnathon Rourke

            A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM:

By the time you have read the enclosed program and reports, you
should have concluded that such a program, and one that is legal,
could not have been created by an amateur.

Let me tell you a little about myself. I had a profitable business
for 10 years. Then in 1979 my business began falling off. I was doing
the same things that were previously successful for me, but it wasn't
working. Finally, I figured it out. It wasn't me, it was the economy.
Inflation and recession had replaced the stable economy that had been
with us since 1945.I don't have to tell you what happened to the
unemployment rate... because many of you know from first hand
experience. There were more failures and bankruptcies than ever before.

The middle class was vanishing. Those who knew what they were doing
invested wisely and moved up. Those who did not, including those who
never had anything to save or invest, were moving down into the ranks
of the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR
GET POORER." The traditional methods of making money will never allow
you to "move up" or "get rich", inflation will see to that.

You have just received information that can give you financial
freedom for the rest of your life, with "NO RISK" and "JUST A LITTLE
BIT OF EFFORT." You can make more money in the next few months than you
 have ever imagined. I should also point out that I will not see a penny of this
money, nor anyone else who has provided a testimonial for this
program. I have already made over 4 MILLION DOLLARS!I have retired
from the program after sending thousands and thousands of programs.

Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way
. It works exceedingly well as it is now. Remember to e-mail a copy
of this exciting report to everyone you can think of. One of the
people you send this to may send out 50,000...and your name will be on everyone of
them!

Remember though, the more you send out the more potential customers
you will reach.

So my friend, I have given you the ideas, information, materials and
opportunity to become financially independent. IT IS UP TO YOU NOW!

                              "THINK ABOUT IT"

Before you delete this program from your mailbox, as I almost did,
take a little time to read it and REALLY THINK ABOUT IT. Get a pencil
and figure out what could happen when YOU participate. Figure out the
worst possible response and no matter how you calculate it, you will
still make a lot of money! You will definitely get back what you
invested. Any doubts you have will vanish when your first orders come
in. IT WORKS!

                         Jody Jacobs, Richmond, VA

     HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF
DOLLAR$

                               INSTRUCTIONS:

This method of raising capital REALLY WORKS 100% EVERY TIME.
I am sure that you could use up to $50,000 or more in the next 90
days. Before you say "BULL... ", please read this program carefully.

This is not a chain letter, but a perfectly legal money making
opportunity. Basically, this is what you do: As with all multi-level
businesses, we build our business by recruiting new partners and
selling our products. Every state in the USA allows you to recruit
new multi-level business partners,
and we offer a product for EVERY dollar sent. YOUR ORDERS COME BY
MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal
selling. You do it privately in your own home, store or office. This
is the GREATEST Multi-Level Mail Order Marketing anywhere.

                          This is what you MUST do:

1. Order all 4 reports shown on the list below (you can't sell them
if youdon't order them).
-- For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT
YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN
ADDRESS (in case of a problem) to the person whose name appears on
the list next to the report.  MAKE SURE YOUR RETURN ADDRESS IS ON
YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS!
-- When you place your order, make sure you order each of the four
reports. You will need all four reports so that you can save them on
your computer and resell them.
-- Within a few days you will receive, via e-mail, each of the four
reports. Save them on your computer so they will be accessible for you to send
to the 1,000's of people who will order them from you.

2. IMPORTANT DO NOT alter the names of the people who are listed next
to each report, or their sequence on the list, in any way other than
is instructed below in steps "a" through "f" or you will lose out on
the majority of your profits. Once you understand the way this works,
you'll also see how it doesn't work if you change it. Remember, this
method has been tested,and if you alter it, it will not work.
a. Look below for the listing of available reports.
b. After you've ordered the four reports, take this advertisement and
      remove the name and address under REPORT #4. This person has
made it through the cycle and is no doubt counting their $50,000!
c. Move the name and address under REPORT #3 down to REPORT #4.
d. Move the name and address under REPORT #2 down to REPORT #3.
e. Move the name and address under REPORT #1 down to REPORT #2.
f.  Insert your name/address in the REPORT #1 position.

     Please make sure you COPY ALL INFORMATION, every name and
address,
     ACCURATELY!

3. Take this entire letter, including the modified list of names, and
save it to your computer. Make NO changes to the instruction portion
of this letter.

   Your cost to participate in this is practically nothing (surely
you can afford $20). You obviously already have an Internet
connection and e-mail is FREE!



          There are two primary methods of building your downline:

                       METHOD #1: SENDING BULK E-MAIL

Let's say that you decide to start small, just to see how it goes,
and we'll assume you and all those involved send out only 2,000
programs each. Let's also assume that the mailing receives a 0.5%
response. Using a good list the response could be much better. Also,
many people will send out hundreds of
thousands of programs instead of 2,000. But continuing with this
example, you send out only 2,000 programs. With a 0.5% response, that
is only 10 orders for REPORT #1. Those 10 people respond by sending
out 2,000 programs each for a total of 20,000. Out of those 0.5%, 100
people respond and order REPORT #2. Those 100 mail out 2,000 programs
each for a total of 200,000.
The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000
send out 2,000 programs each for a 2,000,000 total. The 0.5% response
to that is 10,000 orders for REPORT #4. That's 10,000 $5 bills for
you. CASH!!! Your total income in this example is $50 + $500 + $5,000
+ $50,000 for a total of
$55,550!!! REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000
PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS 
PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF 
EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000.
Believe me, many people will do justthat, and more! By the way, your cost to
participate in this is practically nothing.  You obviously already have an Internet
connection and e-mail is FREE!!! REPORT #2 will show you the best
methods for bulk e-mailing, tell you where
to obtain free bulk e-mail software and where to obtain e-mail lists.



                METHOD #2 - PLACING FREE ADS ON THE INTERNET

Advertising on the internet is very, very inexpensive, and there are
HUNDREDS of FREE places to advertise. Let's say you decide to start
small just to see how well it works. Assume your goal is to get ONLY
10 people to participate on your first level. (Placing a lot of FREE
ads on the Internet will EASILY get a larger response.) Also assume that 
 everyone else in YOUR ORGANIZATION gets ONLY 10 downline members.
 Follow this example to achieve the STAGGERING results below:

1st level--your 10 members with $5.......................................$50
2nd level--10 members from those 10 ($5 x 100)..................$500
3rd level--10 members from those 100 ($5 x 1,000)...........$5,000
4th level--10 members from those 1,000 ($5 x 10,000).....$50,000
                   THIS TOTALS ---------->$55,550

Remember friends, this assumes that the people who participate only
recruit 10 people each. Think for a moment what would happen if they
got 20 people to participate! Most people get 100's of participants!
THINK ABOUT IT! For every $5.00 you receive, all you must do is e-mail them
 the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE
 ON ALL ORDERS! This will guarantee that the e-mail THEY send out with YOUR
name and address on it will be prompt because they can't advertise
until they receive the report!

                              AVAILABLE REPORTS

                *** Order Each REPORT by NUMBER and NAME ***
                                   Notes:
-- ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT
     ACCEPTED.
-- ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL.
-- Make sure the cash is concealed by wrapping it in at least two
sheets of paper. On one of those sheets of paper, include:
     (a) the number & name of the report you are ordering, (b) your
e-mail address, and (c) your name & postal address.

                  PLACE YOUR ORDER FOR THESE REPORTS NOW:




 
REPORT #1 "The Insider's Guide to Advertising for Free on the
Internet"

ORDER REPORT #1 FROM :
B.Lapole
P.O. Box 642
Spring, Texas 77383-0642

REPORT #2 "The Insider's Guide to Sending Bulk E-mail on the Internet"


ORDER REPORT #2 FROM:
A. Williams
10606 Twin Circle
Montgomery, Texas 77356

REPORT #3 "The Secrets to Multi-level Marketing on the Internet"


ORDER REPORT #3 FROM:
R. Ehrgott
10130 Mossycup
Conroe, Texas 77304

REPORT #4 "How to Become a Millionaire Utilizing the Power of
Multi-level Marketing and the Internet"


ORDER REPORT #4 FROM:
D. Vasicak
479 Bennett Street
Luzerne, PA 18709
                           

          About 50,000 new people get online every month!
                     
                         ******* TIPS FOR SUCCESS *******
-- TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow
the directions accurately.
-- Send for the four reports IMMEDIATELY so you will have them when
the orders start coming in because: When you receive a $5 order, you
MUST send out the requested product/report.
-- ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE.
-- Be patient and persistent with this program. If you follow the
     instructions exactly, your results WILL BE SUCCESSFUL!
-- ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED!

                   ******* YOUR SUCCESS GUIDELINES *******
             Follow these guidelines to guarantee your success:

If you don't receive 20 orders for REPORT #1 within two weeks,
continue

advertising or sending e-mails until you do. Then, a couple of weeks
later you should receive at least 100 orders for REPORT#2. If you don
't, continue advertising or sending e-mails until you do. Once you
have received 100 or more orders for REPORT #2, YOU CAN RELAX,
because the system is already working for you, and the cash will
continue to roll in!

                       THIS IS IMPORTANT TO REMEMBER:
Every time your name is moved down on the list, you are placed in
front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by
watching which report people are ordering from you. If you want to
generate more income, send another batch of e-mails or continue
placing ads and start the whole process again! There is no limit to
the income you will generate from this business!

Before you make your decision as to whether or not you participate in
this program. Please answer one question. DO YOU WANT TO CHANGE YOUR
LIFE? If the answer is yes, please look at the following facts about
this program:

1. You are selling a product which does not Cost anything to PRODUCE,
SHIP OR ADVERTISE.
2. All of your customers pay you in CASH!
3. E-mail is without question the most powerful method of
distributing information on earth. This program combines the
distribution power of e-mail together with the revenue generating
power of multi-level marketing.
4. Your only expense--other than your initial $20 investment--is your
time!
5. Virtually all of the income you generate from this program is PURE
PROFIT!
6. This program will change your LIFE FOREVER.

ACT NOW!Take your first step toward achieving financial independence.
Orderthe reports and follow the program outlined above--SUCCESSwill
be yourreward.

                 Thank you for your time and consideration.

PLEASE NOTE: If you need help with starting a business, registering a
business name, learning how income tax is handled, etc., contact your
localoffice of the Small Business Administration (a Federal Agency)
1-800-827-5722 for free help and answers to questions. Also, the
InternalRevenue Service offers free help via telephone and free
seminars aboutbusiness tax requirements. Your earnings are highly
dependant on youractivities and advertising. The information
contained on this site and in the report constitutes no guarantees
stated nor implied. In the event that it is determined that this site
or report constitutes a guarantee of any kind, that guarantee is now
void. The earnings amounts listed on this site and in the report are
estimates only. If you have any questions of the legality of this
program, contact the Office of Associate Director for Marketing
Practices, Federal Trade Commission, Bureau of Consumer Protection in
Washington, DC.


/////////////////////////////////////////////////////////////////
Remove at boardgames@goplay.com
/////////////////////////////////////////////////////////////////