Subject: [Dime] Capabilities update draft

From: "Victor Fajardo" <[email-masked]>
Date: Mon, 24 Aug 2009 09:19:08 -0400

Hi Folks,

We would like to progress the capabilities-update draft
(http://tools.ietf.org/html/draft-ietf-dime-capablities-update-00). Ravi and
other folks have commented on this work but its best if we get some more
feedback especially from folks who work on diameter implementations. It's a
short document and fairly easy reading. We plan to let this cook in the WG
for about a month or so and then take the next step. If you have concerns,
pls state so as well.

Regards,

victor

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 25 Aug 2009 13:19:37 +0900

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)

---

From: Niklas Neumann <[email-masked]>
Date: Tue, 25 Aug 2009 14:21:22 +0200

Hello everybody,

I was wondering if there should be some implementation considerations 
included. I see the following problem:

A Diameter client has a list of potential Diameter servers. When the 
client starts it picks a random server from this list and tries to 
initialize its applications. If there is an error the client picks the 
next server until a working server is found or the list is exhausted. 
Now if during operation the Diameter server "retracts" one of its 
applications the draft says that the client should disconnect the 
transport layer connections. Unfortunately from the point of view of the 
application it is not clear what to do because such a behavior was not 
anticipated before the capabilities-update app.

I see a couple of options:
a) The client can try to re-initialize the application as if the client 
was restarted.
b) The client can handle this like it would handle a Disconnect-Peer-Request
c) The client can signal a Diameter error to the application (e.g. 
DIAMETER_APPLICATION_UNSUPPORTED)
d) The client can ignore the application and hope that it has 
implemented an error handling which can cope with this.

My point is that a capabilities-update can set a Diameter application 
into a state that might not have been anticipated by the particular 
application implementation. Therefore it might be a good idea to give 
implementors some guidelines on what to keep in mind when extending a 
Diameter client without regarding the applications.

Also, I am probably late to the party and missed the initial discussion 
about the document but the motivation is not clear to me. Maybe some 
examples or use-cases can help to understand in which scenarios you 
envision the capability-updates to be used.

Best regards
   Niklas

Victor Fajardo wrote:
> (http://tools.ietf.org/html/draft-ietf-dime-capablities-update-00). Ravi 
> and other folks have commented on this work but its best if we get some 
> more feedback especially from folks who work on diameter 
> implementations. It’s a short document and fairly easy reading. We plan 
> to let this cook in the WG for about a month or so and then take the 
> next step. If you have concerns, pls state so as well.
> 
>  
> 
> Regards,
> 
> victor//
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

-- 
Niklas Neumann - University of Goettingen, Institute of Computer Science
http://user.informatik.uni-goettingen.de/~nneuman1/
Tel: +49 551 39-172053