At Wed, 14 May 2008 12:20:21 +0800,
Eric Burger wrote:
Inline
On May 4, 2008, at 5:12 AM, Eric Rescorla wrote:
I originally reviewed version -06 of this document
(2008-02-8). Examining the diff, it does not appear to me that any of
my comments from my previous review. Looking back in my mail folder, I
don't see any reasponses from the authors telling me my review was
wrong, so I'm retransmitting it here.
-Ekr
$Id: draft-ietf-simple-imdn-06-rev.txt,v 1.1 2008/02/08 18:17:54 ekr
Exp $
This document describes a mechanism for IM senders to request status
notifications for their IMs. The sender attaches a header specifying
the status conditions he wants to be notified of and intermediaries
and the receiving UA notify the sender (or someone else of his choice)
subject to policy constraints.
One thing I'm not clear on is how the recipient determines where to
send the IMDN. Are they supposed to read the "From" field? One thing
that I don't get is how the IMDN-Route header interacts here.
It looks to me like this gets stuffed in the "To" in the IMDN.
You are right - we go on and on about IMDN-Record-Route, but we never
explicitly say what to do if there is no IMDN-Record-Route. How about
the following text, inserted after the IMDN-Record-Route handling
paragraph:
If there is no IMDN-Record-Route header field, the IM Recipient
MUST send the IMDN to the URI in the From header field.
That seems reasonable.
What happens if someone puts an IMDN-Record-Route that points
to an IMDN-ignorant UA?
We need to make it clear that an intermediary can only intermediate on
its own behalf.
How about the following text change in the Intermediary Behaviour
section:
OLD
An intermediary MAY choose to remain on the path of IMDNs for a
specific IM. It can do so by adding a CPIM IMDN-Record-Route header
field as the top IMDN-Record-Route header field and populating it with
its own address.
NEW
An intermediary MAY choose to remain on the path of IMDNs for a
specific IM. It can do so by adding a CPIM IMDN-Record-Route header
field as the top IMDN-Record-Route header field. The value of this
field MUST be the intermediary's own address.
OK.
I was mulling over whether this introduces a security issue.
Specifically, what if a malicious intermediary wants to perform a DDoS
attack on an unsuspecting UA? The intermediary could spew a bunch of
messages towards other UAs, asking them to send IMDNs to DDoS target
by setting the topmost Record-Route to the target machine. The good
news is this takes a similar amount of resources as that intermediary
attacking the target directly. The bad news is the IMDN-Record-Route
mechanism provides a mechanism for the malicious node to hide its
identity from the target. The same issue arises if the node simply
puts in the target node as the From field of the IM and requests an
IMDN. The only trace would be server logs, which could identify the
malicious node as the source of the bogus IMDN requests.
How about we add the following to the "threats in the IMDN system"
list in the Security Considerations section:
A malicious intermediary or node attempts to flood a target
node with IMDNs by inserting the target's address in the From
field or IMDN-Record-Route field
And this text towards the end of the section:
One way to address the potential for a malicious node to use
the IMDN system to anonomize attacks is to log all IMDN
requests on the IM Recipient User Agent. This allows for tracking
of attacks, if only after they occur. Note this also puts a
burden on
the IM Recipient User Agent host. Limited User Agents may not
be able to preserve much of a log.
This seems to accurately characterize the situation. I'm not really
ready to offer an opinion on whether this is an acceptable
security situation--that seems like a question for the WG and the
IESG...
Other comments: I would avoid the term "non-repudiation" if at all
possible in S 5.3 and later. It's just so overloaded now that it's
hard to know what it means.
Fixed
S 6.5. A little more explanation of why IMDN-Record-Route is useful
would help.
Done
S 7.1.1.1. Why does Message-ID need any randomness at all as opposed
to uniqueness? And if it needs randomness, why is 32 enough?
The randomness property makes it more difficult for malicious nodes
guessing Message-IDs and thus being able to pass IMDNs through
filtering mechanisms.
IYHO, is 32-bits enough? You're the expert; I'm just guessing!
So, unsurprisingly, it depends.
Is your mental model that you have a list of n valid message-ids
"outstanding" at once and you want the probability of an attacker
guessing one to be sufficiently small? With a 32-bit space,
the chance is n/2^32. So, if you're just treating this as a
sort of spam filter, then it's probably fine. But if a single
bad message getting through is fatal, then, no, it's not.
The other thing I would say is that if you want ids to be
unguessable, then you probably want to say that they should
be generated with a cryptographically secure random number
generator. There are lots of PRNGs that produce uniform distributions
but that are predictable and that won't do here, right?
S 7.1.3. Note that you can pack the state into the messageid if
you're willing to make large message ids and hte stte is small.
Message-ID could be used for tracking in addition to IMDN, so
combining the two would not be a good thing.
OK. It was just a side note.
S 11.1
An IMDN Payload is an XML document [6] that MUST be well formed and
MUST be valid according to schemas, including extension schemas,
available to the validater and applicable to the XML document. The
IMDN Payload MUST be based on XML 1.0 and MUST be encoded using
UTF-8.
Is this a requirement that the receiver validate the XML?
On the one hand, I suppose it is. On the other hand, that is totally
unenforceable. Can this one slide under the radar?
Got me. This seems like the kind of question that comes up whenever
we have schema. Have the Apps ADs taken a position on that.
S 12.1.1. Why can't anonymous senders request notifications?
Where would one send the IMDN to?
This goes back to my confusion over where the notifications go.
Seems fine with this explanation.
-Ekr
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf