Age | Commit message (Collapse) | Author |
|
It isn't always the case. The information isn't currently used in
any case.
|
|
Simpler, no duplication of similar makefiles and makes for
better dependencies. (Aka, recursive make considered harmful.)
|
|
|
|
|
|
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.
|
|
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.
|
|
|
|
The application provides an implementation of the Diameter protocol
as defined in RFC 3588.
|