Subject: RE: session-id

From: <[email-masked]>
Date: Tue, 22 Apr 2003 11:43:01 +0300

There is a ready made solution for this problem, the Diameter Session-Id AVP. It's eternally unique and created by the AAA client (PAA). With this approach the sessions in PANA are subset with the sessions in the AAA (Diameter) backend.

See below the description of this AVP from draft-ietf-aaa-diameter-17.txt.

8.8  Session-Id AVP

   The Session-Id AVP (AVP Code 263) is of type UTF8String and is used
   to identify a specific session (see section 8). All messages
   pertaining to a specific session MUST include only one Session-Id AVP
   and the same value MUST be used throughout the life of a session.
   When present, the Session-Id SHOULD appear immediately following the
   Diameter Header (see section 3).

   The Session-Id MUST be globally and eternally unique, as it is meant
   to uniquely identify a user session without reference to any other
   information, and may be needed to correlate historical authentication
   information with accounting information. The Session-Id includes a
   mandatory portion and an implementation-defined portion; a
   recommended format for the implementation-defined portion is outlined
   below.

   The Session-Id MUST begin with the sender's identity encoded in the
   DiameterIdentity type (see section 4.4). The remainder of the
   Session-Id is delimted by a ";" character, and MAY be any sequence
   that the client can guarantee to be eternally unique; however, the
   following format is recommended, (square brackets [] indicate an
   optional element):
   <DiameterIdentity>;<high 32 bits>;<low 32 bits>[;<optional value>]

   <high 32 bits> and <low 32 bits> are decimal representations of the
   high and low 32 bits of a monotonically increasing 64-bit value. The
   64-bit value is rendered in two part to simplify formatting by 32-bit
   processors. At startup, the high 32 bits of the 64-bit value MAY be
   initialized to the time, and the low 32 bits MAY be initialized to
   zero. This will for practical purposes eliminate the possibility of
   overlapping Session-Ids after a reboot, assuming the reboot process
   takes longer than a second. Alternatively, an implementation MAY keep
   track of the increasing value in non-volatile memory.

   <optional value> is implementation specific but may include a modem's
   device Id, a layer 2 address, timestamp, etc.

   Example, in which there is no optional value:
      accesspoint7.acme.com;1876543210;523

   Example, in which there is an optional value:
      accesspoint7.acme.com;1876543210;523;[email-masked]

   The Session-Id is created by the Diameter application initiating the
   session, which in most cases is done by the client. Note that a
   Session-Id MAY be used for both the authorization and accounting
   commands of a given application.

> -----Original Message-----
> From: ext Alper Yegin [mailto:[email-masked]]
> Sent: 19 April, 2003 02:57
> To: Mohan Parthasarathy; Yoshihiro Ohba
> Cc: [email-masked]
> Subject: Re: session-id
> 
> 
> > I am not sure I understand the question. I thought the session id
> > is used for identifying the session related stuff of a given PaC.
> > But this leads to the problem of unique session ids. It might
> > be easy if the PAA allocates a session ID (like SPI allocated by
> > the receiver) to make it unique across all the PaCs.
> 
> This makes sense. It might even make sense to have an 
> NAI-like session id,
> e.g., [email-masked], if we care about global 
> identification for
> any reason.
> 
> Alper
> 
>