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

[Eric Rescorla <[e-mail]>]

On Fri, Jan 19, 2018 at 11:31 AM, Toerless Eckert <[e-mail]> wrote:

> Thanks, Eric
>
> Just voicing my personal opinions, hopefully helpfull to resolve the
> issues.
>
> A) Rant
>
> > 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.
> >
> > it's not clear to me why arbitrary people should be allowed to
> instantiate queries.
>
> Because 25 years experience of multicast geeks has been the network
> operators have
> been incapable or unwilling to diagnose multicast, so users had to help
> users.
>
> [no comment needed]
>

This doesn't seem like a good reason to create significant security issues
for the rest of the Internet.



> B) solution proposals
>
> > 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.
>
> Right. But 9.2 already says as much, so whats the minimum (weakest)
> better form of filtering that you would approve of to resolve your issues ?
>

I don't know yet. At the moment I'm at the point where the security analysis
of this document seems severely lacking (as evidenced by my so easily
finding issues that weren't addressed) so I'm not sure what appropriate
resolutions would be.


I would suggest three points:
>
> B.1) deny third-party mtrace for user devices by default
>
> | Mtrace queries SHOULD by default only be processed when sent with a
> source
> | address directly connected to the interface on which it is received. They
> | MAY additionally be filtered by the presence of IGMPv3/MLDv2 explicitly
> | tracked receiver state for the indicated multicast traffic (group
> {,source})
> | from the source address.
>
> This would still leave the gap of source address spoofing within a subnet,
> but we have IMHO ample precedent how the IETF leaves this problem to
> subnet mechanisms like L2 switch IP/MAC binding (e.g.: no protection
> against
> this in most DHCP, IGMP/MLD, PIM, ...).
>

I think the key point here is that this is not solely about unauthorized
access
but also about amplification. To expand on that point, another source of
potential
amplification is to inject a Request but to lie about the requesting
address,
thus causing the final router to send a big response.






> B.3) Expectation/setup of non on-path spoofing between third-party
>      (OAM device) query initiator and responder.
>
> The third part seems to be setting expectations straight for mtrace
> originators,
> not sure if this should go into 5.1 (sending mtrce query) or 9. (security).
>
> | Originators of mtrace queries are not protected against spoofed replies.
> | They should therefore only originate Mtrace queries to addresses for
> | whom they can assume reasonable protection against spoofing:
> |
> | - User equipment should send mtrace queries only to known default
> |   router addres(es) on its connected LANs. This is more secure than
> |   sending to all-routers address because it minimizes the opportunity
> |   for spoofing of replies by other nodes on the subnet  (in the absence
> |   of subnet specific mechanisms to protect against that attack).
> |
> | - Network OAM equipment (permitted as sources for Mtrace queries through
> |   administrative action as explained in 9.2) should send mtrace queries
> |   only to destination addresses of network equipment for whom spoofing
> |   of replies along the path is not an attack vector. Typically this is
> the
> |   same set of devices administratively configured to permit this Mtrace
> |   originators requests.
>


> Give or take the wording, but would these three items if worded according
> resolve your discuss ? To re-summarize:
>
>   B.1) deny third-party mtrace for user devices by default
>   B.2) explicit permitting third-party mtrace only to trusted
>        (OAM equipment) originators
>   B.3) Expectation/setup of non on-path spoofing between third-party
>        (OAM device) query initiator and responder.
>
> C) I hate address filtering security, but given how this has been a
> protocol waiting for 20++ years for an RFC i don't think we should
> muck around with the protocol now and further delay it. Aka: as
> nice-to-have larger query-ids would be - is it worth doing this
> protocol change now given the above security model ?
>

I'm not sure how long this is waiting is really that persuasive an argument
against doing the right thing. We know addresses are untrustworthy and
it's not like I'm suggesting you introduce real comsec between the
endpoints (though some form of real authentication would clearly be
better).

-Ekr



The most likely next step to overcome the trusted path issue between
> query initiator to query responder is to make an mtrace yang model where
> you can actually initiate an mtrace via netconf/yang, aka: replace
> the query with netconf. Like you would today just ssh into the
> LHR and run a local mtrace client there.
>
> Alas, i see no easy way to get back to support A) in a lightweight
> fashion ;-(
>
> Cheers
>     Toerless
>
> On Thu, Jan 18, 2018 at 07:34:59AM -0800, Eric Rescorla 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.
> >
> > - 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.
> >
> > - Anyone on-path can forge responses.
> >
> > 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.
> >
> > 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.
> >
> >
> > ----------------------------------------------------------------------
> > 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?
> >
> >
> > 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"
> >
> >
> > 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"/
> >
> >
> >
> > 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.
> >
> >
> > 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?
> >
> >
> > S 3.2.6.
> >
> >           0x01    # of the returned Standard Response Blocks
> >
> > Nit: Do you want to say 0x0001
> >
> > 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.
> >
> >
> > 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.
> >
> > 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.
> >
> >
> > _______________________________________________
> > MBONED mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mboned
>
> --
> ---
> [e-mail]
>