RE: : NASreq Origin-AAA-Protocol and Authors 48 hours: RFC 4005

On 7/4/2005 07:19 AM, Glen Zorn (gwz) wrote:
>[email protected] <mailto:[email protected]> supposedly scribbled:
>
> > David,
> >
> > This would be useful for so that when a Diameter server gets a
> > message, it can tell if it is from a RADIUS client or Diameter
> > client. In the RADIUS case, then, the Diameter server knows enough to
> > limit the message size to a size the RADIUS client can handle.
> >
> > I hope this clears the major issue that Glenn had with NASREQ so that
> > we can finally complete this document.
>
>Basically, I think that it will work; it may need a little work, but it's 
>hard to tell what's actually in the document that will be 
>published.  Would it be possible to generate a new document that is 
>actually the text that will become the RFC for review?

Glen, the RFC Editor copied you with a link to the current version of the 
text on 5/27.

>  I'm not sure if the rather onerous restriction on Diameter AVP lengths 
> was actually added, for example.  If so, it needs to be made conditional 
> on the value of this new AVP.  I suspect that an IANA policy of 
> "Specification Required" would make more sense than "IETF Consensus"; not 
> sure why we need a WG to define the limiting properties of, for example, 
> TACACS+.  Also, since the document AFAIK does not (& probably should not) 
> describe the behavior required of the Diameter peer if the value of the 
> Origin-AAA-Protocol AVP is other than 1 (RADIUS), the other two values 
> seem unnecessary, if not ambivalent.

The additional values are indeed, unnecessary.  They can be removed if they 
offer no value.
The concensus clause was a cut and paste, and as you point out, probably 
should be revised.

Anyone else?

Dave.


> >
> > I think it is also important for the WG to speak up about this, if
> > anyone has any trouble with it.  If no major dissenting voices
> > speak-up by Friday, could you update the text and we can see if we
> > can finalize this.
> >
> > thanks,
> > John
> >
> >> -----Original Message-----
> >> From: [email protected]
> >> [mailto:[email protected]]On Behalf Of ext David Mitton
> >> Sent: 02 July, 2005 16:30
> >> To: [email protected]
> >> Cc: Bernard Aboba; Loughney John (Nokia-NRC/Helsinki); [email protected];
> >> Pat Calhoun; Bert Wijnen; Kessens David (Nokia-NET/MtView)
> >> Subject: [AAA-WG]: NASreq Origin-AAA-Protocol and Authors 48
> >> hours: RFC
> >> 4005
> >>
> >>
> >> On 6/14/2005 08:22 AM, Bernard Aboba wrote:
> >>> I don't think we want to revise the Base spec at this point.
> >>>
> >>> I would be OK with adding the AVP to the NASREQ document as long as
> >>> this doesn't require a lot of text to define it or explain how it
> >>> is used.
> >>
> >> Below is a proposal to add an AVP to NASreq (to be RFC4005) which
> >> identifies the origin protocol for messages that are translated from
> >> another protocol, primarily
> >> RADIUS.
> >>
> >> If there is concensus, we will add this to the the RFC and close it.
> >> If there are any other protocols to add to the list, speak up.
> >>
> >> Thanks for your cooperation and patience.
> >>
> >> Dave.
> >>
> >> -------------------------------------
> >>
> >> Last set of Text changes for RFC 4005
> >> <draft-ietf-aaa-diameter-nasreq-17.txt>
> >>
> >> ABNF Changes;
> >>
> >> Add line [ Origin-AAA-Protocol ]
> >> Before [ Origin-State-Id ]
> >> To the following:
> >>          AA-Request, Page 10
> >>          AA-Answer, Page 12
> >>          RA-Request, page 13
> >>          RA-Answer, page 14
> >>          ST-Request, page 15,
> >>          ST-Answer, page 15,
> >>          AS-Request, page 16,
> >>          AS-Answer, page 17,
> >>          AC-Request, page 18,
> >>          AC-Answer, page 19
> >>
> >>
> >> Add to Section 9.1, page 56, between 2nd and 3rd bullets
> >>
> >>   - The Diameter Origin-AAA-Protocol AVP MUST be created and added
> >>     indicating the protocol type of the source of the message.
> >>
> >> Add to Section 9.2, page 60, after
> >> "      -  The response's Origin-Host information is created
> >> from the FQDN
> >>           of the RADIUS message's source IP address.  The same FQDN
> >>           is also stored to a Route-Record AVP.
> >> "
> >> bulleted paragraph:
> >>
> >>          - The response MUST have an Origin-AAA-Protocol AVP added
> >>            indicating the protocol of origin of the message.
> >>
> >>
> >> Add line to end of table in section 9.3
> >>
> >> Origin-AAA-Protocol   408  9.3.6   Enumerated  | M  | P  |
> >>>  V  |  Y  |
> >>
> >>
> >> Add Section:
> >> 9.3.6 Origin-AAA-Protocol
> >>
> >> The Origin-AAA-Protocol AVP (AVP Code 408) is of the type
> >> Enumerated and
> >> should be inserted in a Diameter message translated by a
> >> gateway system
> >> from another AAA protocol, such as RADIUS.  It identifies the source
> >> protocol of the message to the Diameter system receiving the message.
> >>
> >> The supported values are:
> >>          1       RADIUS
> >>          2       TACACS
> >>          3       Proprietary
> >>
> >>
> >>
> >> Accounting AVP Table inserts:
> >>
> >> Section 10.1  Page 72 (alpha order)
> >> and Section 10.2.1 Page 75
> >> and Section 10.2.2 Page 77
> >> Add line:
> >>          Origin-AAA-Protocol     0-1     0-1
> >>
> >>
> >> Section 11 IANA Considerations
> >> Sect 11.2  AVP Codes;  change /407/408/
> >>
> >> Add Section 11.6
> >>
> >> 11.6 Origin-AAA-Protocol AVP Values
> >>
> >>     As defined in section 9.3.6, the Origin-AAA-Protocol AVP (AVP
> >> Code 408) defines
> >>     the values 1-3. All remaining values are available for
> >> assignment via IETF
> >>     Consensus [IANA].
> >>
> >>
> >>
> >> ---
> >>
> >> This will cause some page adjusting and TOC changes.
> >> Notify IANA of use of code 408 and enumeration
> >>
> >> ==============================================================
>
>Hope this helps,
>
>~gwz
>
>Why is it that most of the world's problems can't be solved by simply
>   listening to John Coltrane? -- Henry Gabriel