Subject: [AAA-WG]: [issue] Proxy behavior

From: Bernard Aboba <[email-masked]>
Date: Tue, 22 May 2001 13:06:46 -0700 (PDT)

I'd note that pp. 10 of the aaa-issues-04 draft from November has an
action item to "properly define the terms proxy, broker, redirect server,
transparent and nontransparent proxy in the Diameter specifications and
describe how each type of device should function." 

The current base draft defines "Proxy Server" as a routing proxy, and
re-direct is also defined, but other proxy types aren't. The proxy draft, 
http://www.ietf.org/internet-drafts/draft-ietf-aaa-proxies-01.txt also
takes a shot at this, but the terminology is not consistent with the base
draft or the transport draft. So at a minimum we need to clean up the
terminology and definitions so that all drafts are consistent. 

However, I think we should probably aim higher. The operation of proxies
is so basic that it is hard to understand the base spec without a mental
model of how they work. So I think that the proxy draft material needs to
be consolidated with the base Proxy material on pp. 59-61, and this should
probably be moved closer to the front of the base draft. 

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. 

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:

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?

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? 

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.

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. 

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. 

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.  

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?

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?

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.