1. 1 draft-ietf-aaa-diameter-15.txt Diameter Base Update Diameter 15 currently in IESG Review Lots of comments from the IESG Some open nits, mostly text edits needed. What follows is a list of the bigger things to take care of.

2. 2 draft-ietf-aaa-diameter-15.txt Definitions, etc. It would be good to define "user". I *think* that "user" means the entity requesting or using some resource, in support of which a Diameter client has generated a request" or some such. I'm trying to avoid confusion in discussions of authentication -- is it the Diameter node or the resource- requesting entity that is being authenticated? ECONNREFUSED is a Unix errno value. Probably, OS- independent terminology should be used. Resolution for both, agree with the above, add text.

3. 3 draft-ietf-aaa-diameter-15.txt Transport Issues Does "RESET call" mean "send a TCP RST bit" (or the SCTP equivalent? Or does it mean that a connection should be terminated without benefit of the DPR exchange? How many SCTP streams should be created? May be created? Open – should this be in the transport doc?

4. 4 draft-ietf-aaa-diameter-15.txt Redirect Agents It is very far from clear to me that redirect agents are or should be application-agnostic. Is routing on the contents of application-specific fields to be disallowed? I note that 6.13 permits per-user redirection, and user names are not in the routing table defined earlier. (I'm perfectly happy with the answer "the WG has considered and rejected this point".) Open.

5. 5 draft-ietf-aaa-diameter-15.txt Reserved Bits Should the spec indicate that the reserved bits MUST be ignored by receivers, rather than sending an error? It makes it hard to start using those bits, given the current language. "Be liberal in what you receive", etc. Resolution – use suggestion above.

6. 6 draft-ietf-aaa-diameter-15.txt Security Nits Discuss DNSsec? What TLS or IPsec certificates should be checked for? More specifically: the peer discovery mechanisms MUST be tied to a security authorization model. Each peer to which a node speaks must be authorized for some role. The Diameter implementation must have some list of credentials that are acceptable *for this role*. That point should probably be discussed here, and possibly in the Security section as well. (Note that suitable checking in this fashion relegates DNSsec issues to availability, and not even much of that -- an attacker can't impersonate a legimate peer, because it lacks the right credentials.) 6.1.8 Proxy-Info has security implications, and probably requires an embedded HMAC with a node-local key.

7. 7 draft-ietf-aaa-diameter-15.txt MAY Encr flag Why is the flag "MAY Encr" when confidentiality is mandatory? I don't see the reasoning for some of the settings of that flag. For example, I would think that the authentication- and authorization-related flags would require protection, to guard against deletion to prevent the operation from taking place, or to spoof the result. This also illustrates confusion between the need for integrity protection vs. confidentiality. It would be good to give some general guidance, for the benefit of people defining Diameter applications. Need some discussion.

8. 8 draft-ietf-aaa-diameter-15.txt RAA Message 8.3 The RAA message is curious, and perhaps the answer to my question is in another AAA document. That said -- in general, something like a NAS can't do user authentication by itself. Instead, it's going to use Diameter facilities to send something upstream. Ultimately, it's the Diameter server that is going to make the decision. That suggests that reauthenticate is more of a command from the server to the client, where the server will, at some point, issue a disconnect message. The current model seems to suggest a sequence of server->client: RAR client->server: authentication info } repeated server->client: authentication info } client->server: success/failure In other words, there's a nested exchange. Is that intended? What Session- ID should be used? Will Diameter implementations be confused by that sort of sequence? There's a state machine lurking in the background here, I think. Open

9. 9 draft-ietf-aaa-diameter-15.txt Reordering of Accounting Records I'm concerned that I don't see a way for a server to detect a total ordering of accounting records for a session. This would be useful, for example, when processing interim records. The situation I'm concerned about is as follows. Suppose a client sends an interim record to a proxy or relay agent. The upstream link from the agent is experiencing a transient problem. Or perhaps the agent crashes and reboots, but has stored the pending records in non-volatile storage. In the meantime, the client sends another interim message via another path, either because it suspects a failure or because it is using multiple peers for load-sharing. This second record can be received first. I suspect that the easiest solution is to require that Accounting-Record- Number be monotonically increasing within a session. Open

10. 10 draft-ietf-aaa-diameter-15.txt End to End security The definition of "end-to-end security" needs to be improved. The description here makes it clear that the phrase "end-to- end security" is not, in fact, accurate. If that transform can (or should) be applied by an intermediate node, which is strongly suggested by this section, it is not "end-to-end". I suspect that something like "object security" is closer, though still not quite right. Open.

11. 11 draft-ietf-aaa-diameter-15.txt End to End Authorization Is there some document that discusses the end-to-end (and I mean that literally here) Diameter authorization model? I know that it was discussed in the WG, but I don't see anything on that here. What's I'm looking for -- somewhere -- is some discussion on how, say, a NAS "knows" that it will be paid when an authorization comes from five proxies away. Open

12. 12 draft-ietf-aaa-diameter-15.txt Vendor ID I get confused here w.r.t. the value of zero (0) for Vendor-ID. It is not clear to me if value of zero is used ever or that instead one always leaves out the optional Vendor-ID field if the value is supposed to be zero. If the latter, are they saying that the field Vendor-ID SHOULD NEVER contain a value of zero.... As I said, I find it confusing By the way, vendor IDs (the SMI values they are using here) cannot be zero, cause the value zero is RESERVED, see http://www.iana.org/assignments/enterprise-numbers. It would be an improvement I think if they actually mentioned that they are indeed the Enterprise-Numbers as registered by IANA. http://www.iana.org/assignments/enterprise-numbers Resolution – fix as proposed.

13. 13 draft-ietf-aaa-diameter-15.txt Filter Rules IPFilterRule and QoSFilterRule -- are the ascii strings white space separated? Are they just one long string without white space? It also bothers me a bit that this is a totally different way of specifying such filters as is done in MIBs and PIBs. I guess such is life. People will have to learn multiple ways of doing the same thing. Oh well. Should these be specified as in MIBs & PIBs?

14. 14 draft-ietf-aaa-diameter-15.txt IPAddress Datatype I wonder if the use of IPAddress as a datatype may not be misleading. MANY MANY people know this as a SNMP/SMI datatype to represent an IPv4 address. And so I immediatly jumped up and though: what about IPv6. Turns out that they use this datatype for both IPv4 and IPv6. And one has to figure it out based on the length. I know that we have abandoned all that in the SMI world, and we use a discriminated union instead namely an InetAddressType and InetAddress. Resolution – use InetAddressType and InetAddress.

15. 15 draft-ietf-aaa-diameter-15.txt DiameterIdentity This is derived from OctetString. I wonder if it should be UTF-8 based. Are FQDNs ever going to be internationalized in the future? If so, then I think they should be UTF-8 based. That probably means derived from OctetString, but having additional UTF-8 semantics as for the UTF8String. Now if they do give it UTF8 semantics, then sect 5.6.4, where they start talking about comparing such strings needs work too. PAF’s suggested action: 1) Create a profile of stringprep to be used for diameter 2) Add the following text to "UTF8String", after first paragraph: The string is to be normalized according to the specification in RFC XXXX [xxxx] 3) Add reference to the profile Reference: [xxxx] RFC XXXX, stringprep profile for use in the Diameter protocol. Anyone do anything like this before?

16. 16 draft-ietf-aaa-diameter-15.txt IANA Registry From IANA: This stuff is a bit confusing. I was wondering if it would be possible for the authors to include an initial registry in this document? This would help the IANA when it comes time to take care of the IANA actions. If that is not possible can one of the authors assist me in getting this registry set-up? Solution: help get an initial registry setup.