Subject: [AAA-WG]: Re: [Issue] Proxy Behavior

From: Pat Calhoun <[email-masked]>
Date: Tue, 29 May 2001 18:17:26 -0700

First, thanks for the comments. I will send another e-mail with my proposed
remaining fixes for this fix (I sent another one earlier which I also sent
an e-mail to).

> One interesting point made in the SIP spec is that types of proxy behavior 
> are situational, so that a proxy may act as a routing proxy for one type 
> of message, a re-direct for another, etc. I'm curious if this logical 
> applies to Diameter or not. This complicates the capabilities exchange 
> considerably, because it implies that a proxy's capabilities might vary 
> depending on the message type, destination realm, etc. 

Correct, and I believe that the rules for advertising are quite clear in
the text that I sent out today.

> 
> At various points in the base spec, it is hard for me to understand what 
> type of proxy is being referred to, or whether the text applies to *all* 
> proxy types as defined in the various drafts. Some examples: 

Right, and I believe that the text that I sent earlier today handles this.
All types of Agents are now well defined. The term proxy was being abused,
so I now use agent as the umbrella term. An agent is either a relay, proxy,
redirector or server.

> 
> 1. pp. 21, base. "If such an AVP is received by a Proxy or Redirect 
> Server, the message MUST be forwarded to its logical destination and MUST 
> NOT be rejected." Do all proxy types defined in the proxy doc behave this 
> way, or just routing proxies? Might a policy proxy NOT forward such a 
> message? 

This is now fixed to state that relay and redirectors DO NOT return an
error when this occurs.

> 
> 2. pp. 27, base. "Proxies receiving messages that contain the 
> Destination-FQDN AVP MUST verify whether they are able to forward Diameter 
> messages to the host specified in the AVP, and if so, MUST forward the 
> message to the host in question." Again, do *all* proxy types behave this 
> way, or just routing proxies? Might a policy proxy not do this? 

Check, I believe this is now described much better in the text. This is
*always* done by proxy and relay agents.

> 
> 3. pp. 28, base. "A receiver of a DRI message which does not have any 
> extensions in common with the sender MUST return a DSI message to the 
> peer..." Would suggest we explicitly state how proxy types are expected to 
> behave with respect to a DRI message. It makes sense that a routing proxy 
> MUST advertise *, as would a re-direct. A policy proxy might not advertise 
> wildcard though, right? Is there ever a situation where a proxy might 
> implement different capabilities based on mesage type or the realm of the 
> request? So for mitton.com, proxy might handle MIP requests, but for 
> internaut.com I wouldn't ('cause he only paid for dialup)? Or is this 
> something I handle by not authorizing those types of access? Clarification 
> on the role of capabilities exchange versus authorization would be 
> helpful. 

The text I sent earlier now describes how advertises what (actually, I made
a couple of adjustments, so I will re-send my whole Issue 50 fix later).

> 
> 4. pp. 39. "An e2e error occurs when a Diameter entity sends a message and 
> either an intermediate proxy or the home server wishes to return a 
> failure." Term "intermediate proxy" is not defined in the glossary. Also, 
> I thought that e2e errors were removed based on discussion at IETF50. 

I do not recall such a conversation, and we agreed that it was necessary at
the last interim meeting.

> 
> 5. pp. 44 "The Device-Status-Ind message MUST NOT be proxied, but MAY be 
> forwarded". If "proxy" means "routing proxy" as indicated in the glossary 
> you'd think these two actions would be equivalent. Obviously there is 
> some distinction here but it's not defined well, so it's hard to make out 
> what the difference is. 

Check, and the problem, which was raised once, is that the forwarding and
routing text are in two seaprate places in the draft. I have now consolidated,
and cleaned up, the text into section 5.

> 
> 6. pp. 56. Section 11.1.1 talks about the realm-based routing table. Table 
> entries include Domain Name, Extension Identifier, Action. Making 
> forwarding decisions based on extension seems complicated to me, and I'd 
> prefer to do away with it if possible. I would assume that 
> re-directs and routing proxies always have wildcard in the extension 
> identifier, but they still need to track the extensions of their 
> downstream neighbors, right? This is one of the reasons why having a 
> server support all extensions would simplify things. 

Wildcard is an extension, and is a wildcard, so ANY packets MAY be
sent to an agent that advertises this. I believe that the text is much
clearer on this now.

> 
> 7. On pp. 57 it says "the local server MAY apply its local 
> policies to the message by including new AVPs prior to forwarding". This 
> doesn't seem like routing proxy behavior, more like a policy proxy, right? 

check, and fixed.

> 
> 8. pp. 57 "a message that does not contain any of the above AVPs MUST NOT 
> be routed". Not clear about the distinction been forwarding and routing 
> used here. Is this distinct from forwarding and proxying, and if so what 
> operations does routing include? 

check, and fixed.

> 
> 9. pp. 59. This section talks about behavior of stateless and stateful 
> proxies. I think that more detail on behavior of these types is needed 
> up front. Given that a stateful proxy maintains session 
> state, I think that more explicit guidance is needed on how this is done 
> in the face of reboot indications, network partitions, etc. It's not an 
> easy problem. 

check, and I (hope) it is fixed.

Sending fixes right now,

PatC