diff options
Diffstat (limited to 'lib/diameter/doc/src')
| -rw-r--r-- | lib/diameter/doc/src/diameter.xml | 55 | ||||
| -rw-r--r-- | lib/diameter/doc/src/notes.xml | 126 |
2 files changed, 170 insertions, 11 deletions
diff --git a/lib/diameter/doc/src/diameter.xml b/lib/diameter/doc/src/diameter.xml index ea175a58b8..b0cff32c9a 100644 --- a/lib/diameter/doc/src/diameter.xml +++ b/lib/diameter/doc/src/diameter.xml @@ -794,14 +794,6 @@ Messages larger than the specified number of bytes are discarded.</p> Defaults to <c>16777215</c>, the maximum value of the 24-bit Message Length field in a Diameter Header.</p> -<warning> -<p> -This option should be set to as low a value as is sufficient for the -Diameter applications and peers in question, since decoding incoming -messages from a malicious peer can otherwise generate significant -load.</p> -</warning> - </item> <tag><c>{restrict_connections, false @@ -920,6 +912,49 @@ Options <c>monitor</c> and <c>link</c> are ignored.</p> Defaults to the empty list.</p> </item> +<marker id="strict_mbit"/> +<tag><c>{strict_mbit, boolean()}</c></tag> +<item> +<p> +Whether or not to regard an AVP setting the M-bit as erroneous when +the command grammar in question does not explicitly allow the AVP. +If <c>true</c> then such AVPs are regarded as 5001 errors, +DIAMETER_AVP_UNSUPPORTED. +If <c>false</c> then the M-bit is ignored and policing +it becomes the receiver's responsibility.</p> + +<p> +Defaults to <c>true</c>.</p> + +<warning> +<p> +RFC 6733 is unclear about the semantics of the M-bit. +One the one hand, the CCF specification in section 3.2 documents AVP +in a command grammar as meaning <b>any</b> arbitrary AVP; on the +other hand, 1.3.4 states that AVPs setting the M-bit cannot be added +to an existing command: the modified command must instead be +placed in a new Diameter application.</p> +<p> +The reason for the latter is presumably interoperability: +allowing arbitrary AVPs setting the M-bit in a command makes its +interpretation implementation-dependent, since there's no +guarantee that all implementations will understand the same set of +arbitrary AVPs in the context of a given command. +However, interpreting <c>AVP</c> in a command grammar as <b>any</b> +AVP, regardless of M-bit, renders 1.3.4 meaningless, since the receiver +can simply ignore any AVP it thinks isn't relevant, regardless of the +sender's intent.</p> +<p> +Beware of confusing mandatory in the sense of the M-bit with mandatory +in the sense of the command grammar. +The former is a semantic requirement: that the receiver understand the +semantics of the AVP in the context in question. +The latter is a syntactic requirement: whether or not the AVP must +occur in the message in question.</p> +</warning> + +</item> + <marker id="string_decode"/> <tag><c>{string_decode, boolean()}</c></tag> <item> @@ -1231,9 +1266,7 @@ is not the length of the message in question, as received over the transport interface documented in &man_transport;.</p> <p> -If <c>exit</c> then a warning report is emitted and the parent of the -transport process in question exits, which causes the transport -process itself to exit as described in &man_transport;. +If <c>exit</c> then the transport process in question exits. If <c>handle</c> then the message is processed as usual, a resulting &app_handle_request; or &app_handle_answer; callback (if one takes place) indicating the <c>5015</c> error (DIAMETER_INVALID_MESSAGE_LENGTH). diff --git a/lib/diameter/doc/src/notes.xml b/lib/diameter/doc/src/notes.xml index c5df63a7f0..7726d761bd 100644 --- a/lib/diameter/doc/src/notes.xml +++ b/lib/diameter/doc/src/notes.xml @@ -42,6 +42,132 @@ first.</p> <!-- ===================================================================== --> +<section><title>diameter 1.9.2.1</title> + + <section><title>Fixed Bugs and Malfunctions</title> + <list> + <item> + <p> + Don't report 5005 (DIAMETER_AVP_MISSING) errors + unnecessarily.</p> + <p> + An AVP whose decode failed was reported as missing, + despite having been reported with another error as a + consequence of the failure.</p> + <p> + Own Id: OTP-12871</p> + </item> + <item> + <p> + Fix relay encode of nested, Grouped AVPs.</p> + <p> + A fault in OTP-12475 caused encode to fail if the first + AVP in a Grouped AVP was itself Grouped.</p> + <p> + Own Id: OTP-12879 Aux Id: OTP-12475 </p> + </item> + <item> + <p> + Improve decode performance.</p> + <p> + The time required to decode a message increased + quadratically with the number of AVPs in the worst case, + leading to extremely long execution times.</p> + <p> + Own Id: OTP-12891</p> + </item> + <item> + <p> + Match acceptable peer addresses case insensitively.</p> + <p> + Regular expressions passed in an 'accept' tuple to + diameter_tcp or diameter_sctp inappropriately matched + case.</p> + <p> + Own Id: OTP-12902</p> + </item> + <item> + <p> + Improve watchdog and statistics performance.</p> + <p> + Inefficient use of timers contributed to poor performance + at high load, as did ordering of the table statistics are + written to.</p> + <p> + Own Id: OTP-12912</p> + </item> + <item> + <p> + Fix start order of alternate transports.</p> + <p> + A transport configured with diameter:add_transport/2 can + be passed multiple transport_module/transport_config + tuples in order to specify alternate configuration, + modules being attempted in order until one succeeds. This + is primarily for the connecting case; for example, to + allow a transport to be configured to first attempt + connection over SCTP, and then TCP in case SCTP fails. + Multiple module tuples can be paired with a single config + tuple, but in this case the start order was reversed + relative to the order in which the modules were specifed.</p> + <p> + Own Id: OTP-12929</p> + </item> + <item> + <p> + Fix decode of Grouped AVPs containing errors.</p> + <p> + RFC 6733 says this of Failed-AVP in 7.5:</p> + <p> + <taglist><item><p><c> In the case where the offending AVP + is embedded within a Grouped AVP, the Failed-AVP MAY + contain the grouped AVP, which in turn contains the + single offending AVP. The same method MAY be employed if + the grouped AVP itself is embedded in yet another grouped + AVP and so on. In this case, the Failed-AVP MAY contain + the grouped AVP hierarchy up to the single offending AVP. + This enables the recipient to detect the location of the + offending AVP when embedded in a + group.</c></p></item></taglist></p> + <p> + It says this of DIAMETER_INVALID_AVP_LENGTH in 7.1.5:</p> + <p> + <taglist><item><p><c> The request contained an AVP with + an invalid length. A Diameter message indicating this + error MUST include the offending AVPs within a Failed-AVP + AVP. In cases where the erroneous AVP length value + exceeds the message length or is less than the minimum + AVP header length, it is sufficient to include the + offending AVP header and a zero filled payload of the + minimum required length for the payloads data type. If + the AVP is a Grouped AVP, the Grouped AVP header with an + empty payload would be sufficient to indicate the + offending AVP. In the case where the offending AVP header + cannot be fully decoded when the AVP length is less than + the minimum AVP header length, it is sufficient to + include an offending AVP header that is formulated by + padding the incomplete AVP header with zero up to the + minimum AVP header length.</c></p></item></taglist></p> + <p> + The AVPs placed in the errors field of a diameter_packet + record are intended to be appropriate for inclusion in a + Failed-AVP, but neither of the above paragraphs has been + followed in the Grouped case: the entire faulty AVP + (non-faulty components and all) has been included. This + made it difficult to identify the actual faulty AVP in + all but simple cases.</p> + <p> + The decode is now adapted to the RFC, and implements the + suggested single faulty AVP, nested in as many Grouped + containers as required.</p> + <p> + Own Id: OTP-12930</p> + </item> + </list> + </section> + +</section> + <section><title>diameter 1.9.2</title> <section><title>Fixed Bugs and Malfunctions</title> |