Re: Eric Rescorla's Discuss on draft-ietf-mboned-mtrace-v2-22: (with DISCUSS and COMMENT)

On Thu, Mar 15, 2018 at 11:23 PM, Kerry Meyer <[email protected]> wrote:

> Hi Eric and others,
>
> We are sorry for the long delay. We have been carefully considering the
> points you have raised and how best to address them. We hope that the
> proposed resolutions of those points will satisfy your concerns.
>
>           Kerry
>
> > On Jan 18, 2018, at 7:34 AM, Eric Rescorla <[email protected]> wrote:
> >
> > Eric Rescorla has entered the following ballot position for
> > draft-ietf-mboned-mtrace-v2-22: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.
> html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-mboned-mtrace-v2/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > The security considerations of this document are inadequate. My review
> > turns up at least the following potential issues which do
> > not seem to be addressed or even discussed:
> >
> > - Amplification: this protocol does not appear to verify that the
> >  sender of the query actually owns the IP it claims. Because
> >  responses are much larger than queries, this allows for an amplification
> >  attack, especially if the client is able to send a query that elicits
> >  multiple replies. One defense here would be to fill the rest of the
> packet
> >  with zeroes, thus somewhat reducing the amplification factor. Access
> >  control would also help.
> >
> We understand that access control is required to protect against this and
> other threats from malicious senders. This will be specified in section 9..2
> as follows;
>
> "A router MUST support a mechanism to filter out queries from clients
> and “requests” from peer router addresses that are unauthorized or
> that are beyond a specified administrative boundary.  This filtering
> could, for example, be specified via a list of allowed/disallowed client
> and peer addresses or subnets for the Mtrace2 protocol port. If a query
> or request is received from an unauthorized address or one beyond the
> specified administrative boundary, the Query/Request MUST NOT be
> processed. The router MAY, however, perform rate limited logging of such
> events."
>

This seems like an improvement, but still seems to allow amplification to
any
client which is a valid requestor. So, if I have one such on my network,
then
I am subject to DoS?



> Additional text has been added to section 9.7 (see later in this mail) to
> explicitly map this and other concerns to the recommended prevention
> mechanism.
>
> > - Forgery of responses: because the query id is so short, an attacker
> >  can generally produce a message which has a nontrivial chance of
> >  corresponding to an extant query. This could be addressed by having
> >  a query ID that was large and random.
> >
>
> Because there are 2**16 possible query ID values, an average of 2**15
> forged response attempts would be required to “hit” the actual query ID for
> a given extant query. The amount of time to do this would far exceed the
> lifetime of an extant query/response.


Why is that true? It's possible to send massively more than 2^15
messages/sec.


Even assuming that a targeted client has multiple extant queries at a given
> time, the chance of matching one is still quite small. More importantly,
> the required access control for the Mtrace protocol port (section 9.2,
> aforementioned) provides protection against an unauthorized malicious
> sender injecting bogus request packets.
>

How does this protect against forgery to a client.


> > - Anyone on-path can forge responses.
> >
> The forger would need to match the query ID and the dynamically allocated
> client (source) port (REF: section 3.2.1) to create a valid reply message
> that would pass validity checks at the client.
>

Yes, but if you are on-path you know all this stuff.

-Ekr


> > In addition, Section 9.4 seems inadequate. Isn't it generally the case
> that
> > who is sending to who is sensitive? This seems like a fairly serious
> privacy
> > obstacle to using this protocol at all.
> >
> The requirement to specify a list of “trusted” clients (section 9.2)
> provides a mechanism to avoid the dissemination of this information to
> unauthorized hosts.
>
> > It seems like many of the issues I raise above would be fixed or at
> > least mitigated by having some sort of access control mechanism.  I
> > understand why it might be the case that it's not practical to have
> > full communication security between the links (though it would of
> > course be desirable), but it's not clear to me why arbitrary people
> > should be allowed to instantiate queries.
> >
> Agreed. The requirement to restrict the addresses permitted to send Mtrace
> messages to a given router is specified in an expanded version of section
> 9.2.
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > S 1.
> >   When an Mtrace2 client initiates a multicast trace, it sends an
> >   Mtrace2 Query packet to the LHR or RP for a multicast group and,
> >
> > This seems a bit confusing as there are multiple LHRs for the group.
> > Can you rephrase?
> >
> The word “the” preceding “LHR ...” has been changed to “an”.
> >
> > S 2.1.
> >   ALL-[protocol]-ROUTERS group
> >      It is a link-local multicast address for multicast routers to
> >
> > This is grammatically funny. Perhaps remove "It is”
> >
> The words “It is” have been removed from the cited paragraph and other
> similar adjacent paragraphs.
> >
> > S 3.
> >   additional information associated with the message.  If an
> >   implementation receives an unknown TLV type for the first TLV in a
> >   message (i.e., the header TLV), it SHOULD ignore and silently discard
> >   the entire packet.  If an implementation receives an unknown TLV type
> >   for a subsequent TLV within a message, it SHOULD ignore and silently
> >   discard the entire packet.
> >
> > ISTM that these cases are handled identically so is there a reason
> > not just to remove the first sentence and change the second one to
> > "for any TLV"/
> >
> >
> These two cases have been combined to reflect the fact that there is no
> difference in handling.
>
> “If an implementation receives an unknown TLV type for any TLV in a
> message, it SHOULD ignore and silently discard the entire packet.”
>
> >
> > S 3.2.1
> >   An Mtrace2 Query is usually originated by an Mtrace2 client which
> >   sends an Mtrace2 Query message to the LHR.  When tracing towards the
> >   source or the RP, the intermediate routers MUST NOT modify the Query
> >   message except the Type field.
> >
> > I'm not sure I follow this. Don't routers either (a) not touch this at
> all
> > or (b) if they are the LHR, change Type from Query -> Request and then
> > add a response block? This text seems to not really capture either case..
> >
> The paragraph has been modified based on this comment as follows;
>
> “An Mtrace2 Query is originated by an Mtrace2 client which
> sends an Mtrace2 Query message to the LHR.  The LHR modifies only
> the Type field of the Query TLV (to turn it into a “Request”)
> before appending a Standard Response Block and forwarding it upstream.
> The LHR and intermediate routers handling the Mtrace2 message when
> tracing upstream MUST NOT modify any other fields within the
> Query/Request TLV. Additionally, intermediate routers handling
> the message after the LHR has converted the Query into a Request
> MUST NOT modify the type field of the Request TLV. If the actual number
> of hops is not known, an Mtrace2 client could send an initial Query
> message with a large # Hops (e.g., 0xff), in order to try to trace the
> full path.”
> >
> > S 3.2.4.
> >      Note that Mtrace2 does not require all the routers on the path to
> >      have synchronized clocks in order to measure one-way latency.
> >
> > It's not clear to me how one does this. Can you expand?
> >
> The paragraph has been modified to clarify this point.
>
> >
> > S 3.2.6.
> >
> >          0x01    # of the returned Standard Response Blocks
> >
> > Nit: Do you want to say 0x0001
> >
> Done, thanks.
>
> > Also, an example of the case covered by this section would help, I think.
> >
> >
> >
> > S 4.4.
> > It might be clearer to move this up a bit in the text as it sort of
> > summarizes some cases you already covered before. It would be easier
> > if it provided an overview instead.
> >
> This section is located where it is because of the sequence of operations:
> Query->Request->Reply.
> >
> > S 5.9.
> >
> >   In this case, the Mtrace2
> >   client may receive multiple Mtrace2 Replies from different routers
> >   along the path.  When this happens, the client MUST treat them as a
> >   single Mtrace2 Reply message.
> >
> > Can you please describe how the client reassembles multiple messages
> > into one. I think I may know how to do this, but the document should
> > tell me.
> >
> The paragraph has been expanded based on this comment as follows;
>
> "When the NO_SPACE error occurs, as described in Section 4.2, a router
>  will send back an Mtrace2 Reply to the Mtrace2 client, and continue
>  with a new Request (see Section 4.3.3).  In this case, the Mtrace2
>  client may receive multiple Mtrace2 Replies from different routers
>  along the path.  When this happens, the client MUST treat them as a
>  single Mtrace2 Reply message by collating the augmented response
>  blocks of subsequent replies sharing the same query ID, sequencing
>  each cluster of augmented response blocks based on the order in
>  which they are received."
> > S 8.
> >   The following new registries are to be created and maintained under
> >   the "RFC Required" registry policy as specified in [4].
> >
> > Why did you choose RFC Required rather than Specification Required?
> > This just seems to unduly put load on the ISE.
> >
> >
> Agreed. The sentence has been modified based on this comment.
>
> ******
> Addtional Note:
>
> According to above considerations, we added a new section 9.7 as shown
> below;
> ===
> 9.7 Specific Security Concerns
>
>   This subsection describes some of the specific security concerns and
>   exposures that have been considered during the design of the Mtrace2
>   protocol. Where applicable, the exposures are mapped to the
>   corresponding remedy listed in the previous subsections.
>
> 9.7.1 Request and Response bombardment
>
>   A malicious sender could generate invalid and undesirable Mtrace
>   traffic to hosts and/or routers on a network by eliciting responses to
>   spoofed or multicast client addresses. This could be done via forged
>   or multicast client/source addresses in Mtrace Query or Request
>   messages. The recommended protections against this type of attack are
>   described in sections 9.1, 9.2, 9.5, and 9.6 above.
>
> 9.7.2 Amplification attack
>
>   Because an Mtrace Query results in Mtrace Request and Mtrace Reply
>   messages that are larger than the original message, the potential
>   exists for an amplification attack from a malicious sender. This
>   threat is minimized by restricting the set of addresses from which
>   Mtrace messages can be received on a given router as specified in
>   section 9.2.
>
> 9.7.3 Leaking of confidential topology details
>
>   Mtrace queries are a potential mechanism for obtaining confidential
>   topology information for a targeted network. Sections 9.2 and 9.4
>   describe required and optional methods for ensuring that Mtrace
>   information is not disseminated to unauthorized hosts.
>
> 9.7.4 Delivery of false mtrace information
>
>    Forged “Reply” messages could potentially provide a host with
>    invalid or incorrect topology information. This threat is mitigated
>    by the following factors:
>
>      - The required filtering of permissible source addresses specified
>        in section 9.2 eliminates the origination of forged replies from
>        addresses that have not been authorized to send Mtrace messages
>        to routers on a given network.
>
>      - To forge a Reply, the sender would need to somehow know the
>        associated two byte query ID for an extant Query and the
>        dynamically allocated source port number.
> ===

_______________________________________________
MBONED mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mboned