Age | Commit message (Collapse) | Author |
|
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.
|
|
|
|
|
|
|
|
* anders/diameter/testsuites/OTP-9553:
Remove forgotten dbg
|
|
|
|
|
|
* anders/diameter/testsuites/OTP-9553:
Don't install Emakefile at release_tests
|
|
Emakefile contained compile flags that caused compilation of suites
to fail in some cases. common_test will generate an Emakefile and
diameter has no need for one of its own.
|
|
Missed the dependency of dictionary beams on diameter_exprecs when
removing compiler modules from app file. The changed build order then
caused the build to fail.
|
|
Conflicts:
lib/diameter/src/app/Makefile
|
|
|
|
|
|
|
|
|
|
* anders/diameter/testsuites/OTP-9553: (23 commits)
Explicit {init,end}_per_group/2 to work around ct bug
Add relay suite
More traffic cases
Add traffic suite
Use groups for parallel testcase execution
Remove gen_sctp suite since it's not diameter-specific
Minor macro cleanup
Minor diameter_ct simplification
Improve xref testcase
Don't require GNU sed to fail testsuite targets
Generate dependencies makefile
Makefile/spec cleanup
Remove old test framework
Add transport and gen_sctp suites
Add watchdog suite
Add stats suite
Add sync suite
Add reg suite
Add dict suite, remove session suite
Move appup tests into app suite and use systools for both
...
|
|
* 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
|
|
* anders/diameter/documentation/OTP-9582:
Minor documentation fixes
|
|
Without these functions the result pages are currently mangled.
The overview page shows that no suites have run, even though all
in fact are, and diameter-specific page is truncated after the
dict suite, which is the first suite that relied on an implicit
{init,end}_per_group/2. This is apparently the result of a recent
common_test commit.
|
|
|
|
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.
|
|
The message being encoded and dictionary module are included
by diameter_codec.erl so diameter_gen.hrl doing so was overkill.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|