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

I see your previous mail suggesting we do a call. That's fine too, if you
want.

-Ekr


On Sat, May 19, 2018 at 3:09 PM, Eric Rescorla <[email protected]> wrote:

>
>
> On Mon, Apr 23, 2018 at 2:10 PM, Kerry Meyer <[email protected]> wrote:
>
>> Hi Eric,
>>
>> Please see inline below for responses to the points raised in your most
>> recent posting regarding the Mtrace V2 draft.
>>
>>                 Kerry
>>
>> On Apr 9, 2018, at 2:07 PM, Eric Rescorla <[email protected]> wrote:
>>
>>
>>
>> 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/stat
>>> ement/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?
>>
>> For valid queries/requests, we specified limiting query/request rates in
>> section 9.5 as follows;
>>
>> "A router may limit Mtrace2 Queries and Requests by ignoring some of
>> the consecutive messages.  The router MAY randomly ignore the
>> received messages to minimize the processing overhead, i.e., to keep
>> fairness in processing queries, or prevent traffic amplification.
>> The rate limit is left to the router's implementation.”
>>
>
> This seems like the kind of thing that's going to get ignored. As a
> comparison point,
> consider QUIC, which forbids sending >3 messages in response to an Initial
> packet.
>
>
>
> In addition, the required use of ACLs on the participating routers
>> prevents the introduction of spoofed query/request packets that would
>> otherwise enable DoS amplification attacks targeting an authorized “query”
>> host. The ACLs provide this protection by allowing queries from an
>> authorized host address to be received only by the router(s) connected to
>> that host, and only on the interface to which that host is attached. For
>> protection against spoofed “request” messages, the ACLs allow requests only
>> from a directly connected peer and allow these messages to be received only
>> on the interface to which that peer is attached.
>>
>> Don’t these provisions address your concern?"
>>
>
> I'm not sure I follow where this is required. The text you are quoting
> here is a lot more vague than this. Why can't "authorized" be anyone?
>
>
>>
>>
>>> 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.
>>
>> A huge number of messages can be randomly ignored as specified in section
>> 9.5.
>>
>
> They can but they need not be. The text above is just a MAY.
>
> Not to put too fine a point on it, what's the problem with actually having
> an ID long enough to prevent off-path attack.
>
>
>
> 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.
>
> To “guess” a query ID and client port would require a rapid burst of trial
> and error packets which would be rendered harmless by the recommended use
> of rate limiting.
>
>
> It doesn't render it harmless, it just reduces the chance of success.
>
>
>
>> > - 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.
>
>
> If a malicious sender knows the query ID and client port of an extant
> query because it is “on path”, then using a bigger query ID wouldn’t help.
> In addition, this information could only be seen by the routers and
> switches within a user’s network. Is there some practical scheme that can
> and should be implemented to protect against this type of attach
> originating from routers and switches within the network of a querying
> client?
>
> I don't know if it's practical or not, but typically we would
> cryptographically protect the values. As I said, this may be impractical,
> but at minimum your security considerations need to adequately document
> this attack and why you can't protect against it.
>
> -Ekr
>
> -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