Subject: [AAA-WG]: [Issue] Routing of session messages defined in base

From: Johan Johansson <[email-masked]>
Date: Tue, 26 Feb 2002 12:36:08 +0100

STR and ASR messages do not belong to any specific application but
    rather to all of them. This means that they will take *any* route to
    a realm even if it is a dead end. They should contain
    Auth-Application-Id avps.

    Submitter name: Johan Johansson
    Submitter email address: [email-masked]
    Date first submitted: 2002-02-26
    Reference:
    Document: base
    Comment type: T
    Priority: 1
    Section: 10.1, 6.8

    Rationale/Explanation of issue:

    Let the realm R be a realm with (separate) home servers N and M for
    NASREQ and MIP and assume that from a given realm the normal route
    passes through a node S that has one NASREQ route to R that will
    make messages enter R via N and one MIP route that will make
    messages enter R via M, e.g.

    S----------------X------------X------------N
    |
    +------------X------------M

    Since M and N have no common application they will not be peers.

    Assume that there is an active MIP session at M that the access
    device determines to terminate by sending an STR. There is nothing
    that prevents S from routing the STR down the N path.

    Requested changes:

    6.8: I haven't thought of a good change to this section yet. But it
    should state that messages regarding a session for a particular
    application should contain the id of that application.

    10.1: Change

                       +-----------------------------------------------+
                       |                  Command-Code                 |
                       |---+---+---+---+---+---+---+---+---+---+---+---+
   Attribute Name      |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA|
   --------------------|---+---+---+---+---+---+---+---+---+---+---+---|
   Acct-Application-Id |0+ |0+ |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Auth-Application-Id |0+ |0+ |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |

to

                       +-----------------------------------------------+
                       |                  Command-Code                 |
                       |---+---+---+---+---+---+---+---+---+---+---+---+
   Attribute Name      |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA|
   --------------------|---+---+---+---+---+---+---+---+---+---+---+---|
   Acct-Application-Id |0+ |0+ |0  |0  |0  |0  |0  |0  |0  |0  |0  |0  |
   Auth-Application-Id |0+ |0+ |0  |0  |0  |0  |0  |0  |1  |0  |1  |0  |

    I guess the RAR messages should probably also have the
    Auth-Application-Id for similar purposes but I'll leave that for
    those who actually use it to comment on.

    j

---

From: "Bob Kopacz" <[email-masked]>
Date: Tue, 26 Feb 2002 10:28:19 -0500

Hi Johan,

I think your issue is very similar to an existing one:

> -----Original Message-----
From: Bob Kopacz [[email-masked]]
Sent: Friday, January 25, 2002 2:49 PM
To: aaa-wg
Subject: [AAA-WG]: [issue] Proxiable messages MUST contain Axxx-Application-Id
AVP

Issue : Proxiable messages MUST contain Axxx-Application-Id AVP
Submitter name:          Bob Kopacz
Submitter email address: [email-masked]
Date first submitted:    01-25-2002
Reference:
Document:                Base
Comment type:            Technical
Priority:                1
Section:

  [I know last-call is over, but pending issues haven't been resolved
  yet, and I think this is a bug].

  Accounting messages and application-specific messages have an
  Axxx-Application-Id AVP which identifies the application (e.g.
  Mobile IP).

  The Auth-Application-Id AVP is currently prohibited from being present
  in the Session-Terminate-Request, Abort-Session-Request, and
  Re-Auth-Request messages.

  This creates a routing problem for intermediate proxy or relay servers
  when receiving an STR/ASR/RAR.  The intermediate server's routing
  table may indicate that, say, Mobile-IP messages route to a different
  next hop than NASREQ messages.  An STR message, however, contains no
  application-id AVP indicating NASREQ-v-MobileIp, so the intermediate
  server doesn't know how to route it.

Requested change:

  1. Require an Auth-Application-Id AVP in Session-Terminate-Request,
  Abort-Session-Request, and Re-Auth-Request messages.

  2. Update occurrence rule tables for the "Auth-Application-Id AVP"
  row, from "0" to "1", for STR and ASR and RAR.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Johan Johansson
> Sent: Tuesday, February 26, 2002 6:36 AM
> To: [email-masked]
> Subject: [AAA-WG]: [Issue] Routing of session messages defined in base
>
>

---

From: Johan Johansson <[email-masked]>
Date: Tue, 26 Feb 2002 16:37:38 +0000

Yes, the issue has been cloned. Sorry about that. I even looked at the 
issues list first but I guess I wasn't paying attention closely enough. 
Nice to see that we are suggesting the same resolution at least.

j

---

From: David Spence <[email-masked]>
Date: Tue, 26 Feb 2002 17:25:08 -0500

I think I agree that Auth-Application-Id should be present in these messages
assuming it is known.  It could help in the routing.

One reason that these messages may not have included the Auth-Application-Id
AVP is that it was thought that this AVP would most likely be used at the
last hop, and the messages under discussion here would usually contain a
Destination-Host AVP to be used at the last hop instead.  However, the

>     +------------X------------M

This scenario might describe a roaming broker (running the Xs) who deploys
separate proxy agents for different applications.