| Age | Commit message (Collapse) | Author |
|---|
|
This is the method added in draft-ietf-dime-rfc3588bis, whereby
a TLS handshake immediately follows connection establishment and
CER/CEA is sent over the secured connection.
|
|
RFC 3588 requires that a Diameter server support TLS but in
practise this seems to mean TLS over SCTP since there are limitations
with running over SCTP: see RFC 6083 (DTLS over SCTP), which is a
response to RFC 3436 (TLS over SCTP). The current RFC 3588 draft
acknowledges this by equating the Inband-Security-Id value TLS
with TLS/TCP and DTLS/SCTP but underlying support for DTLS is
still thin on the ground.
|
|
If TLS has been configured on Inband-Security-Id then the transport
process receives a message from the peer_fsm process indicating
whether or not to upgrade to TLS.
The current draft of RFC 3588 deprecates (but retains for backwards
compatibility) the use of Inband-Security-Id for negotiating TLS,
adding the possibility of TLS having be negotiated before capabilities
exchange. This commit handles the deprecated case.
|
|
When an initial message is received and TLS is a possibility, must
wait for a message from the peer process before either commencing
a handshake or receiving more messages.
|
|
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.
|
|
Conflicts:
lib/diameter/src/app/Makefile
|
|
|
|
|
|
|
|
|
|
* anders/diameter/send_anything/OTP-9581:
Fix sending of messages of arbitrary form
|
|
* anders/diameter/relay_behaviour/OTP-9583:
Fix and clarify relay behaviour
|
|
* anders/diameter/peer_filters/OTP-9580:
Fix and clarify semantics of peer filters
|
|
* anders/diameter/logging/OTP-9579:
Makefile dependency fix
Remove duplicate info from error report at encode failure
Use single format for error_logger reports
Fix improper use of error_logger:info_report/2
|
|
* anders/diameter/header_folding_error/OTP-9577:
Fix header folding bug
|
|
3001 (DIAMETER_COMMAND_UNSUPPORTED) was not sent since the decode
placed the AVP list in the errors field rather than the avps field
of the diameter_packet, causing the subsequent encode to fail.
Session-Id was also set improperly, causing encode to fail even
in this case.
|
|
Leave it up to a handle_request callback to decide whether or
not to filter the peer from which the incoming request was sent.
Reply with 3002 (DIAMETER_UNABLE_TO_DELIVER) on anything but an
answer from the peer.
|
|
Dependency of generated dictionary modules on diameter.hrl
and diameter_gen.hrl was missed.
|
|
|
|
diameter:call/4 can be passed anything, as long as the subsequent
prepare_request callback returns a term that can be encoded.
|
|
An eval filter returning a non-true value caused the call process
to fail and the doc was vague on how an exception was treated.
Clarify that the non-tuple host/realm filters assume messages of
a certain form. Various minor corrections to align code and doc.
|
|
Function doesn't take a format string and arguments as we called it.
Instead use error_logger:info_report/1 and use the same report format
as used for warning and error reports.
|
|
A prepare_request callback from diameter can return a diameter_header
record with in order to set values in the header of an outgoing
request. The fault in diameter_lib:fold_tuple/3 caused encode of
the outgoing request to fail.
|
|
|
|
The events are enabled by default but diameter_sctp neither disabled
nor dealt with them. Reception of such an event caused a transport
process to crash.
|
|
|
|
* anders/diameter/augment_inherited_enums/OTP-9469:
Allow @enum when AVP is defined in an inherited dictionary.
|
|
3GPP standards (for one) extend the values allowed for RFC 3588
AVP's of type Enumerated. Previously, extending an AVP was only
possible by completely redefining the AVP.
|
|
@id defines an application identifier and this is used only when sending
or receiving messages. A dictionary can define only AVP's however,
to be included by other dictionaries using @inherits, in which case it
makes no sense to require @id.
Note that message definitions are not inherited with @inherits, only
AVP's
|
|
|
|
|
|
|
|
plus an example fix.
|
|
|
|
The application provides an implementation of the Diameter protocol
as defined in RFC 3588.
|
