Re: Re-review of draft-ietf-simple-imdn

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.

> 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.

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.

> Overall, this document seems pretty well written and clearly lays out
> the security issues.
>
> That said, I'm concerned about the bounce/reflection threats discussed
> in S 14 (where the sender asks for notification to a third party
> victim).  I'm particularly concerned about the "note" field, since a
> natural implementation seems to be to include an excerpt from the
> message you're acknowledging.  This draft identifies the threat but
> doesn't specify any mechanism for ameliorating them. I think some
> suggested mechanisms would be appoprirate here, or at least some
> analysis of what the potential mechanisms were and why they would or
> would not work.

The <note> field is stupid IMHO.  I'm taking that to the list.  Thanks  
for "noting" it, and I am embarrassed it is in the draft at all.

> 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!

> 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.

> 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?

> S 12.1.1.  Why can't anonymous senders request notifications?

Where would one send the IMDN to?

> S 14.3.  See above comemnts about nonrepudiation

Fixed.

> -Ekr
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf