Re: [Dime] Capabilities update draft

[Sebastien Decugis <sdecugis at nict.go.jp>]

Hello Victor, all,

I have a few comments on the document.

I have two concerns about the security. The first is : I wonder if the
ability to change the DiameterIdentity of the peer during CUR/CUA does
not make it possible to "usurpate" another identity. For example, a
Diameter peer from realm B connects to a relay from realm A providing
proper credentials (CA from realm B), then sends a CUR updating its
DiameterIdentity to some identity in realm C. It is now able to receive
messages destined to realm C, without having a proper credential from
that realm.

The second issue is similar. It concerns the ability to update the peer
identity as well as its Host-IP-Address(es). If a peer is able to
"inject" a CUR inside an open connection, with new DiameterIdentity and
Host-IP-Address information, then the traffic gets redirected to an
arbitrary peer without going through the security check again. This is
probably not usable for TLS-protected channels, but in case of IPsec it
would be difficult to detect that the connection is moved to an address
without protection. I am not really sure if this attack is possible or
not, but I believe it should be described in the Security Considerations
section.

My conclusion would be that I think we should not allow to change the
DiameterIdentity (Origin-Host and/or Origin-Realm) in the CUR. We should
mandate that the transport connection is restarted if the peer identity
is to be changed.


I have also several comments about different parts of the document:

"Diameter nodes conforming to this specification MAY advertise support by
   including..." (section 3, second paragraph)

This is not compatible with the requirements of RFC3588 (section 2.4,
third paragraph):

   "Relay and redirect agents MUST advertise the Relay Application
   Identifier, while all other Diameter nodes MUST advertise locally
   supported applications."

Furthermore, the first paragraph of section 4 is also not consistent
with Diameter routing:

   "When the capabilities of a Diameter node conforming to this
   specification change, it SHOULD notify all of the nodes with which it
   has an open transport connection using the Capabilities-Update-..."

According to RFC3588, the message with application TBD must not be sent
to peers that have not advertised support for this application or
support for the relay application (although in this case, since the
message is not relayable, I believe it should only be sent to peers that
have explicitely advertised the support for the CU application).

My recommendation would be to change the requirement levels: the peer
MUST advertise the support for application, and the peer should notify
all the nodes that have advertised support for Capability Update
application (and not those who did not advertise this support).

It is not related, but I find that the last paragraph of section 4
(Capabilities Update) very confusing ("Since the CUR/CUA messages cannot
be proxied, ...") and I think it could be removed. What do you think?

About the use cases for the Capability Update application, I personally
believe that few implementations will ever support adding or removing
applications without restarting (it seems very difficult to implement
this). I believe that the ability to advertise added or removed IP
endpoints is more useful, especially in the case of SCTP. Anyway, SCTP
is already capable of handling this at its own layer, and provide the
information to upper layers through a notification system. I think it
would be very useful to have a short text describing how everything
interacts if you add a new network interface to a box for example (SCTP
notification, CUR/CUA...). I believe my problem is that I don't really
understand the role of the Host-IP-Address AVPs, sorry for this.

I think that's all I have for the moment :) Sorry for the long mail!

Best regards,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)