aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter/src/app/diameter_capx.erl
AgeCommit message (Collapse)Author
2011-10-17One makefile for src build instead of recursionAnders Svensson
Simpler, no duplication of similar makefiles and makes for better dependencies. (Aka, recursive make considered harmful.)
2011-10-06Add tls support to capabilities exchangeAnders Svensson
To upgrade a connection to TLS or not, that is the question. It is possible for us to send a CER offering both NO_INBAND_SECURITY and TLS and for the peer to answer likewise: RFC 3588 doesn't make clear that a CEA should be unambiguous about the choice of security. Thus, if TLS is offered then assume the server is prepared to for a handshake. Similarly, when receiving a CER, choose TLS if it's offered and be unambiguous about our choice in CEA. There is no ssl:maybe_accept that would let us receive a handshake if it comes or another message if it doesn't. The choice of TLS should probably be made into a callback so that an application can decide based on the peer's Origin-Realm for example. Such a callback could also be used to reject a CER/CEA. Handle Inband-Security-Id values other than NO_INBAND_SECURITY and TLS by assuming that they require no intervention by the transport module, treating them like NO_INBAND_SECURITY. Whether or not this is reasonable (or useful) is unclear. There may be a need for more sychronization than we have on offer. (Having to do something before taking the connection up for example.) Note that diameter_peer_fsm must be upgraded before diameter_capx because of the new return value from diameter_capx:recv_CEA/2.
2011-05-18Initial commit of the diameter application.Anders Svensson
The application provides an implementation of the Diameter protocol as defined in RFC 3588.