Hi,
an alternative would be to assume that all stanzas have been received, if the h value is higher than the number of sent stanzas.
E.g. if client sends 10 stanzas and server responds with h='20', the client would assume that the server has received all 10 stanzas. That means "clearing" the unacknowledged queue and setting everything to acknowledged.
This would follow the "Principle of Least Surprise", since terminating the stream may seem a bit harsh for the user.
Also keep in mind this sentence: "Stream management errors SHOULD be considered recoverable".
Are there any real-world scenarios where this issue could happen? A MitM attack on an unencrypted stream?
Otherwise I think it can only happen due to an programming error.
I think if there any security issues (like a MITM attack), the stream should be closed.
If a wrong 'h' value can only happen due to a programming error, it should be silently handled/logged by programming logic.
Kind regards,
-- Christian
Gesendet: Mittwoch, 07. Februar 2018 um 08:40 Uhr
Von: "Guus der Kinderen" <guus.der.kinde...@gmail.com>
An: "XMPP Standards" <Standards@xmpp.org>
Betreff: [Standards] XEP-0198: Stream should be closed when 'h' value is to high
Von: "Guus der Kinderen" <guus.der.kinde...@gmail.com>
An: "XMPP Standards" <Standards@xmpp.org>
Betreff: [Standards] XEP-0198: Stream should be closed when 'h' value is to high
Hello,
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________XEP-0198 Stream Management relies on a stanza count that is being send as an acknowledgement that a certain amount of session data has been received (the 'h' value). The XEP does not specify what should happen if the acknowledgement is off - when the remote entity appears to acknowledge data that was never / not yet sent.
This situation was discussed briefly in the sidelines of the summit. Terminating the stream came up as the suggested way to handle such a situation. It is worth noting that such behavior is already allowable: "misuse of stream management MAY result in termination of the stream." (but this is not further specified in the XEP).
I propose that the XEP is updated with an instruction to, upon detection of an invalid acknowledgement, terminate the stream with stream error.
Thoughts?
Guus
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
