Subject: [AAA-WG]: [Issue] base draft 07 comments

From: Jacques Caron <[email-masked]>
Date: Fri, 03 Aug 2001 19:32:22 +0200

Submitter name:		Jacques Caron
Submitter email address:	[email-masked]
Date first submitted:		August 3, 2001
Reference:
Document:			Base-07
Comment type:			E
Priority:			1
Section:			throughout
Rationale/Explanation of issue:

This is just an older mail I hadn't formally filed as an issue...

In 1.1:
- second paragraph ("All data delivered by the protocol..."): "and AVPs 
which are explicitly excluded are not included": there isn't anything in 
the ABNF to state that AVPs are excluded.
- last paragraph, "(known as a proxy)" is not consistent with other 
definitions in the draft. Should say "(known as a proxy or relay)".
- also, that paragraph defines a server as either a proxy/relay or as a 
server. It should be called an agent, or the definition should be changed 
to only include the real "server" function.

In 1.3:
- "Accounting record" def is incomplete (ends with "or accounting events 
from several").
- the AVP definition is restrictive. It might include protocol-specific 
data (e.g. routing information), not only pure AAA data.
- "Diameter node" suddenly mentions translation agents, while this is not 
listed in the "Diameter agent" definition
- "Redirector": inconsistent use of "Redirect", "Redirector", 
"Re-direct"... [also throughout the draft].
- the definitions of "Upstream server" and "Downstream server", other than 
the fact that they are reversed ;-> are incorrect: it should be "nodes" and 
not servers, and the definition should be something "a node that is closer 
to the client [resp. home server] in the routing path, relative to a given 
node". It might be the client [resp. home server] itself, so it does not 
necessarily provide "routing services" towards it.

In 2.0
- 5th paragraph ("Diameter proxies..."), "in addition"->"In addition" :-)
- 8th paragraph ("Communication between Diameter peers..."): you mean 
nodes, not peers, right?
- in the same paragraph, the last sentence implies that all messages are 
related to a session (those messages would actually be exchanged between a 
client and a server, not any random set of nodes/peers). This does not 
apply to all the base protocol messages such as CER/CEA, DWR/DWA, etc.).
- in the last paragraph, the semantics of Authorization-Lifetime have not 
been updated

In 2.1
- 3rd paragraph, "A Diameter node MAY initiate connections from any source 
port" *except TBD*?
- same paragraph, "...MAY *be* any of a peer's valid IP addresses."
- where did the 4th paragraph "A given Diameter process SHOULD use the same 
port number ..." come from? That's ugly and unnecessary, as the process 
identity will be communicated in CER/CEA.
- 5th paragraph, there should be a provision for hosts marked "bad" for 
some reason.
- 7th and last paragraph, there is a mix between the sockets API 
(ECONNREFUSED) and TCP/ICMP packet exchanges. Should probably replace 
"ECONNREFUSED (a reset from the transport)" with "a reset from the 
transport" (I think most TCP stacks interpret the ICMP error messages 
themselves and return ECONNREFUSED). Actually, this isn't that much the 
Diameter implementation itself, but the platform it is using. To be clarified.

In 2.3.1:
- 1st paragraph, "Defining a new AVP value is the best approach when a new 
application needs to make use of an existing Diameter application..." Isn't 
that recursive? :-(
- last paragraph, "Furthermore, if the command code on which the AVP value 
is to be used would require a different set of mandatory AVPs be present 
*when the new AVP value is used*, the list of AVPs must accompany the 
request." (needs some rewording)
- should reference something in 11.x, but I don't know what :-(

In 2.3.2:
- 1st paragraph, same application/application problem.
- 2nd paragraph, why MUST it be one of the listed types? Since AVPs are 
opaque to those who don't use them and the AVP type is not included in the 
packet...
- should reference 11.1.1

In 2.3.3
- should reference 11.3

In 2.4
- I guess the whole Acct-Application-Id thing with additional AVPs to 
support in the same Accounting messages invalidates the whole ABNF 
consistency thing...

In 2.5:
- I guess this is historical, but history in a not-yet-published RFC seems 
weird... Why not move the Mobile-IP application to 3?
- I would also swap the E2E security app and NASREQ. The first one is more 
like an extension of the base draft while the second (like Mobile-IP) are 
real AAA apps.
- oh, by the way, it's CMS, not E2E now :-) [also happens in other places 
in the draft]
- 3rd paragraph, "Relay and redirect agents MUST advertise...": what should 
an agent that is a server for some requests (those for users in the local 
domain) and a relay/redirector for others (users in remote domains) advertise?

In 2.6:
- the Host identity received in CER/CEA MUST be saved! I guess there should 
actually be two values: one that is configured (or discovered using DNS, 
SLP...) until the connection is established, and then the official unique 
but consistent value advertised in CER/CEA. Actually, there might be 
several of the configured/discovered identities if the node finds out that 
multiple identities point to the same process.
- as discussed previously, I don't think the role belongs here: a peer 
might be primary for a realm, secondary for another, alternate for yet 
another...

In 2.7
- realm/domain inconsistencies (also throughout the draft), as already 
pointed out by Marta.
- Application identifier: should clarify that accounting and auth messages 
might actually be sent to different servers
- local action/proxy: "See section 6.1.8 for *proxying* guidelines."
- local action/redirect: why home server? Should just be "agent"...
- "Expiration time. Specifies the time which dynamically discovered a route 
table entry expire." -> "Expiration time. Specifies the time which *a* 
dynamically discovered route table entry expireS." ("a" moved, "s" added)
- 2nd paragraph "It is important to note...", "proxies SHOULD NOT reorder 
AVPs": I would say they MUST NOT reorder AVPs of the same type.
- last paragraph: "When a request is routed, the target server MUST have 
advertised the Application Identifier (see section 2.5) for the given 
message, or have advertised itself as a relay or proxy agent."... Mmmm. 
What if the local node has not connected to that agent (not server, btw) 
yet, so doesn't know if it actually advertises the said application? Also, 
what should it do if there's a mismatch here?

In 2.8
- 1st paragraph, translation agents are not defined in 1.3
- 4th paragraph "A stateful agent...", Authorized-Lifetime -> Session-Timeout

In 2.8.1
- 4th paragraph "The example provided...", the last part "which is routed 
back to NAS using Diameter routing AVPs" is no longer true -> "which is 
routed back to NAS using saved transaction state"

In 2.8.2
- 2nd and 5th paragraphs may be a bit too strong: CMS can be applied on 
part of the AVPs only (those that would not be modified, e.g.). And CMS 
will most certainly apply to AVPs that are not modified (i.e. authorization 
answers and accounting requests)

In 3.0
- "r(eserved)  - this flag bit is..." -> "these flag bits are..."
- Hop-by-Hop identifier, "The sender MUST ensure that the Hop-by-Hop 
identifier in a request is locally unique (to the sender)". This might be 
too strong: it actually needs to be unique on a per-connection basis only.
- End-to-End identifier, I guess the method described should only be a 
recommendation, not part of the spec (which should state that it must be 
unique for a given Origin-Host ID for the lifetime of the message)?
- same paragraph, should mention here that a server is supposed to answer 
the same thing it did upon reception of a duplicate, and not take any 
action that would affect state again?

In 3.1
- should renumber everything so that we have something consistent and 
contiguous rather than this sparse table?

In 3.2
- diameter-name    = ALPHA *(ALPHA / DIGIT / "-") should probably be
diameter-name    = ALPHA *(ALPHA / DIGIT / "-") (ALPHA / DIGIT)
(I suppose we don't want command names ending with a dash?)

In 5.3.*:
- I guess we should add some AVPs to advertise the local values of the 
timers (Ti, Tr, Tw, Td...) so that incompatible values are detected 
immediately and the connection torn down with a nice log (a la OSPF IIRC - 
or is it IS-IS?)

In 11.3:
- All values, other than zero... -> All other values, except 0...

On a different subject, something I've been thinking about some time ago, 
but didn't check against the docs: in a roaming environment, what is 
important to an ISP is not that the accounting data from the original 
client be signed by that client (it might not know the client at all, and 
doesn't care). What they care about is that the accounting data be signed 
by their roaming "peer" (partner), i.e. the one that will pay them. 
Actually, if the accounting data includes money (you know, $$$), proxies 
might change that amount on the way (to reflect margins of brokers), but it 
should nevertheless be signed at some point... Some AVPs might actually 
have multiple signatures, or be signed, then checked, then modified (old 
sig removed), and resigned multiple times on the way.

Jacques. 

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

---

From: Cain Brian-BCAIN1 <[email-masked]>
Date: Fri, 3 Aug 2001 14:05:52 -0500

> -----Original Message-----
> From: Jacques Caron [mailto:[email-masked]]
> Subject: [AAA-WG]: [Issue] base draft 07 comments
...
> the ABNF to state that AVPs are excluded.

I believe that the zero maximum, zero minimum occurrences served as an explicit exclusion.

...
> - 3rd paragraph, "A Diameter node MAY initiate connections 

What about a client that listens on SCTP port TBD, but attempts to contact other hosts with a TCP source port TBD?  I don't think that there's a requirement that if a client utilizes a transport on outbound connections, it must support inbound connections on that same protocol, right?  Perhaps the wording should be "A Diameter node MAY initiate connections from any source port, other than the one which they declare they accept incoming connections on."  Unless, perhaps "clients MUST support either TCP or SCTP" means "clients MUST NOT support both TCP and SCTP"...(doubtful).

On that note, 2.1 also says, "Note that the source and destination addresses used in request and replies MAY any of a peer's valid IP addresses"  -- Aren't these addresses going to be limited to only addresses on which the node is listening?

-Brian

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 6 Aug 2001 00:52:09 -0700

...
> the ABNF to state that AVPs are excluded.

I believe that the zero maximum, zero minimum occurrences served as an
explicit exclusion.

<prc> correct
...
> - 3rd paragraph, "A Diameter node MAY initiate connections 

What about a client that listens on SCTP port TBD, but attempts to
contact other hosts with a TCP source port TBD?  I don't think that
there's a requirement that if a client utilizes a transport on outbound
connections, it must support inbound connections on that same protocol,
right?  Perhaps the wording should be "A Diameter node MAY initiate
connections from any source port, other than the one which they declare
they accept incoming connections on."  Unless, perhaps "clients MUST
support either TCP or SCTP" means "clients MUST NOT support both TCP and
SCTP"...(doubtful).

<prc> That proposed text does work for me.

On that note, 2.1 also says, "Note that the source and destination
addresses used in request and replies MAY any of a peer's valid IP
addresses"  -- Aren't these addresses going to be limited to only
addresses on which the node is listening?

<prc> it should state that.

PatC