Subject: [AAA-WG]: [Issue] Unsolicited server-to-client requests

From: Jacques Caron <[email-masked]>
Date: Mon, 11 Jun 2001 14:08:39 +0200

Submitter name: Jacques Caron
Submitter email address: [email-masked]
Date first submitted: 11-Jun-2001
Reference:
Document: Base
Comment type: T
Priority: 2
Section: 5.x
Rationale/Explanation of issue:

The draft is unclear about how unsolicited server-to-client requests are 
routed. It says Destination-Host should be used, but does not say anything 
about Destination-Realm.

I see the following options:
1. Use the Origin-Realm received in previous requests as the 
Destination-Realm.
However, it raises the issue of asymmetrical routing, and thus proxies not 
being able to track session state accurately

2. Do some kind of source-based routing (saving the Route-Records from a 
previous request and using that to route the unsolicited request to the 
client). Is a problem with network topology hiding proxies. Those might be 
forced to be stateful and save route-records on a per-session basis.

3. Have the client send a certificate in the original request, so that 
servers can then send unsolicited requests directly. It should then be 
compulsory for the client to send requests towards the server to update 
session state in the proxies if the server requests modifies state in any 
way. Raises the issue of proxies that might want to "authorize" 
server-to-client requests first, though.

Comments, suggestions?

Jacques.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Jacques Caron <[email-masked]>
Date: Fri, 15 Jun 2001 18:48:17 +0200

Hi,

Following yesterday's call, here are some of the problems raised around 
this issue, and some additional comments:

Trying to have unsolicited requests from server to client follow exactly 
the same path as requests from client to server is a problem, since hosts 
or sessions may go down in between (an unsolicited request might come long 
after any "normal" request from the client, as opposed to answers which 
travel the same path back nearly immediately).

So routing back should not try to match exactly the same path. I see the 
following options here:
- in "regular" requests, include something other than route-records to give 
the path taken, but including alternatives (e.g. other server in a 
"cluster" setup), and use that to route the request. This gives us exact 
path re-use when possible (updating proxy state on the way), and an 
alternate path to ensure reachability (in that case we can't update state 
on the proxy which is unreachable, but since it is unreachable...)
- use some other form of routing (realm-based, direct to client...), but 
force a "regular" request to be sent to the server so that everybody can 
update session state (like an STR after an ASR).

It was also commented that there is no guarantee two similar requests will 
actually follow the same exact path, but I have an open issue on that one 
(#83).

Realm-based routing is not very adapted to this kind of request:
- a server knows it serves a realm, a NAS usually doesn't.
- there is usually a limited number of servers for a given realm, while 
there might be very large numbers of NASes
- realms are normally used to classify user domains, not machine domains 
(that's the purpose of DNS)

Direct communication from home server to client is not always possible 
(there might not be direct IP connectivity between them, filters, NAT, 
anything...)

To solve that problem, it would be possible for a proxy to add an AVP to a 
"regular" request stating where unsolicited requests for this session 
should go to this host which will relay it to destination.

Additional question: should an unsolicited request always be associated to 
a specific session, or could there be "generic" requests to a NAS? I guess 
SNMP would be more adapted for the latter...

I think that's about all the issues that were raised during the meeting on 
this subject. Let me know if I forgot anything.

So, all in all, I see the following updated options (by decreasing order of 
personal preference):
1. When a client sends a request to a server, it includes information on 
how to establish a direct connection back (certificate...).
If at some point there is a breach in IP reachability, the proxy/relay that 
acts as a gateway between the two routing domains includes an AVP stating 
that unsolicited requests should go to it rather than to the Origin-Host 
directly (possibly including certificate info of its own), and it will send 
it to the client. This can possibly happen multiple times, of course. It 
can also be used if a proxy wants to check/modify any request that is sent 
to a client. The AVP might contain multiple DiameterIdenties to provide 
redundancy.
If the request causes a change in the state of the session, the client MUST 
send a regular request back to the server to update state in stateful 
proxies (unless all these proxies add the "get it through me" AVP, which 
might actually be the best solution).

2. Regular requests include AVPs that describe the path taken AND 
alternative servers for each. Server stores last received set of these AVPs 
for each session. When server needs to send a request to a client, it uses 
the contents of these AVPs to source-route the request (in a new AVP). If 
at any given point a host is down, use alternative for that hop.
This is actually very close to #1 with every agent on the way saying "get 
it through me" and no need for additional connections than the existing ones.

3. Use Origin-Realm as Destination-Realm and Origin-Host as 
Destination-Host and use regular message routing. That probably implies 
defining distinct "NAS realms" and/or specific application IDs for these 
requests, as the agents handling those will probably not be the same ones 
as those handling regular "user realms". Once it gets to an agent in the 
NAS realm, Destination-Host is used to send to the appropriate NAS.
If the request causes a change in the state of the session, the client MUST 
send a regular request back to the server to update state in stateful proxies.

4. When establishing a peering (i.e. CER/CEA exchange), include an 
"Alternative-Host" that can be used if this host goes down. All agents need 
to remember where they received the last client-to-server request for a 
given session from, and when they receive a server-to-client request for 
that session, they try to send it to that host, or to the alternate host if 
not possible. This means all agents become stateful (maintain a minimum of 
session state info).

Comments/suggestions welcome. Let me know which option is preferred so I 
can propose some text.

Jacques.