On Fri Sep 19 08:51:14 2008, Sergei Golovan wrote:
Does this 'MUST NOT accept' mean that it must not also forward it
to other
entities?
Yes, that would be accepting it.
>
>> Ejabberd happily accepts namespace-ill-formed stanzas, I don't
know
>> about other servers.
>
> That's a bug and I thought it was corrected in version 2.x.
When I talked to ejabberd author he said that this bug will never
be fixed until
it will be absolutely clear from reading RFC that it's a bug.
Given that ejabberd apparently cannot do this easily, and I spent
well in excess of a week handling some fairly annoying cases of
namespaces in M-Link, I suggest that we work to address this with
rather more pragmatism that simply requiring perfection. Perfect is
the enemy of good, and in this case, it's the enemy of fast, too.
I think we're safe in saying that MUST NOT accept or generate XML
which is not well-formed, and I'll assume this is beyond argument.
(Otherwise you can't tell where the stanza ends, which further
implies that non-well-formed XML gets you a disconnect).
If we want to have "MUST NOT accept non-namespace-well-formed",
though, we'll have to accept that in many implementations, this is
not terribly easy to achieve without taking a sizeable performance
hit, or a vast amount of recoding, or quite possibly both.
In our case, I'm pretty sure that if we receive XML which is not
namespace-well-formed, we'll pass it through in some, and possibly
most circumstances. In some circumstances, we'll be forced into
parsing the stanza contents, in which case we'll at least see the
problematic prefix, but these are highly limited circumstances in the
traditional forward case - the majority of the time we don't parse
the inner XML of stanzas, and doing so would be a significant
performance hit to us.
The fact is there's no good reason clients should be generating bad
XML, and while there's obviously a benefit to servers rejecting it if
possible, it's a reasonably well-known denial of service attack and
the existing deployment doesn't always strip out bad prefixes etc in
all cases. Therefore I think clients need to be made resilient to
these attacks whatever the next RFC revision says, and in particular,
we should be moving to a situation whereby clients don't choke and
drop the connection when they get bad XMLNS like this.
And given that circumstance, it seems to me that requiring servers to
always detect and reject bad prefixes is distinctly onerous.
Instead, stanzas which are not namespace well formed SHOULD be
rejected by the recipient [with a stanza error], and SHOULD NOT cause
a disconnect in clients [ie, don't let this be a DOS]. Clients MUST
NOT generate XML which is not namespace well formed [clients have no
excuse for this behaviour], servers SHOULD NOT forward such XML and
MUST NOT generate it [newly minted XML won't have this problem].
Servers MAY disconnect clients which generate bad XMLNS [potential
DOS], however this does not apply to peer servers.
I think if we require unconditional stringency in servers, that'll
either be ignored as impractical, or result in XMPP being slower than
it really needs to be, or - most likely - both. If client authors
rely on it, then there's sufficient deployed mass out there that it's
likely to be used for DOS purposes for years.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
