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

[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?  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.

> 
> 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