Diameter%20Base%20Update

1
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
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
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
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
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
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
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
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-gtclient RAR
• client-gtserver authentication info repeated
• server-gtclient authentication info
• client-gtserver 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
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
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
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
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/as
  signments/enterprise-numbers. It would be an
  improvement I think if they actually mentioned
  that they are indeed the Enterprise-Numbers as
  registered by IANA.
• Resolution fix as proposed.

13
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
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
DiameterIdentity

• 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.
• PAFs 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
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.