RE: Issue 226: RFC 3576bis and Renumbering

[Bernard Aboba <bernard_aboba@hotmail.com>]

> If the NAS is sending Acct-Session-Id, why not just use that to identify the session? 

This is the approach taken by Diameter.  This suggests to me that the inclusion of an Acct-Session-Id attribute should be at least recommended. 

For example, a Diameter Abort Session Request includes a mandatory Session-Id and optional User-Name AVP ([RFC3588] Section 8.5.1).  Similarly, a Diameter Re-Auth-Request also includes a mandatory Session-Id and optional User-Name AVP ([RFC3588] Section 8.3.1).

        ::= < Diameter Header: 274, REQ, PXY >
                 < Session-Id >
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Realm }
                 { Destination-Host }
                 { Auth-Application-Id }
                 [ User-Name ]
                 [ Origin-State-Id ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]


        ::= < Diameter Header: 258, REQ, PXY >
                 < Session-Id >
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Realm }
                 { Destination-Host }
                 { Auth-Application-Id }
                 { Re-Auth-Request-Type }
                 [ User-Name ]
                 [ Origin-State-Id ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

In contrast to the simple approach taken in RFC 3588, RFC 3576 included support for a wider range of identification attributes:

   Attribute              #    Reference  Description
   ---------             ---   ---------  -----------
   User-Name              1    [RFC2865]  The name of the user
                                          associated with the session.
   NAS-Port               5    [RFC2865]  The port on which the
                                          session is terminated.
   Framed-IP-Address      8    [RFC2865]  The IPv4 address associated
                                          with the session.
   Called-Station-Id     30    [RFC2865]  The link address to which
                                          the session is connected.
   Calling-Station-Id    31    [RFC2865]  The link address from which
                                          the session is connected.
   Acct-Session-Id       44    [RFC2866]  The identifier uniquely
                                          identifying the session
                                          on the NAS.
   Acct-Multi-Session-Id 50    [RFC2866]  The identifier uniquely
                                          identifying related sessions.
   NAS-Port-Type         61    [RFC2865]  The type of port used.
   NAS-Port-Id           87    [RFC2869]  String identifying the port
                                          where the session is.
   Originating-Line-Info 94    [NASREQ]   Provides information on the
                                          characteristics of the line
                                          from which a session
                                          originated.
   Framed-Interface-Id   96    [RFC3162]  The IPv6 Interface Identifier
                                          associated with the session;
                                          always sent with
                                          Framed-IPv6-Prefix.
   Framed-IPv6-Prefix    97    [RFC3162]  The IPv6 prefix associated
                                          with the session, always sent
                                          with Framed-Interface-Id.

> If the NAS isn't sending it (or isn't sending accounting packets at all), then the proposal above already suggests
> changing the NAS behavior.  Why not just require sending Acct-Session-Id in all Access-Requests?

If there are no accounting packets, I'm not sure how the RADIUS server can know that the session did in fact start.  So I think it is reasonable to assume that an Accounting-Request was sent and that it contained an Acct-Session-Id.   However, the entity sending an RFC 3576 packet may not necessarily have access to either authentication or accounting data.  It could, for example, be an IDS system.   So I'm not sure we can mandate Acct-Session-Id. 

Here's what RFC 3576 says about session-identification attributes:

   To address security concerns described in Section 5.1., the User-Name
   Attribute SHOULD be present in Disconnect-Request or CoA-Request
   packets; one or more additional session identification attributes MAY
   also be present.  To address security concerns described in Section
   5.2., one or more of the NAS-IP-Address or NAS-IPv6-Address
   Attributes SHOULD be present in Disconnect-Request or CoA-Request
   packets; the NAS-Identifier Attribute MAY be present in addition.

My suggestion would be to add Acct-Session-Id to the list of SHOULDs. 

The question in my mind is how big the list of MAYs should be. 

In case the Acct-Session-Id is not available for some reason, then the User-Name attribute may not be sufficient to identify a session, so that other attributes might be necessary.  For example, I can see including NAS-Port/NAS-Port-Id to specify the port. 

However, I'm still not sure that all of the MAY attributes are really necessary.  If Session-Id is present this should be sufficient.  If this is not present, then User-Name and NAS-Port/NAS-Port-Id should be cover it.  It is not easy for me to imagine a scenario in which these attributes would not be available, but the other attributes would be. 
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>