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

[Toerless Eckert <[e-mail]>]

On Fri, Jan 26, 2018 at 02:31:18AM +0100, Toerless Eckert wrote:
> > I don't see how that's true. The attack I am concerned about is that you
> > forge a *Request*, not a *Query*. And because the request indicates the original
> > requester.
> 
> Ah, sorry. I thought to remember that the text from you said query.
> I just replied for query messages so far.
                     ^^^^^
*sigh* "request" of course.

Toerless

> > (give or take the subnet local limitations and/or additional L2 security
> > >  required to prohibit intra-l2-lying that i mentioned in my original mail).
> > 
> > Sorry, I'm not seeing this. The point is that you pretend to be a router
> > that is forwarding a Request and fill in a bogus Client Address field. Waht
> > stops that.
> 
> In practical deployments IMHO we can only reasonable get similar solutions to
> what customer are also willing to deploy with PIM. For 99% deployments that
> is configured classificatio of interfaces as trusted/inside-clamshell or
> untrusted/user-facing, and on the untrusted interfaces you don't accept
> requests, just queries. And apply the suggested B.1 policy (Mtracev2 Client
> Address must be connected on receiving interface).
> 
> It might still be useful to have mtrace prepared for customers protecting it
> with IPsec - without requiring special features in mtrace or IPsec for it.
> 
> IMHO for that, we need to have one UDP port for mtrace NNI messages
> (requests), and another for UNI messages (query, response).
> That would allow customers to take a vanilla IPsec implementation and protect
> the mtrace NNI messages and therefore eleiminate interface clamshell
> classification.  In multicast signaling we got this for free: PIM is NNI,
> IGMP/MLD UNI. Easy to distinguish for IPsec.
> 
> > > My points B.1, B.2, B.3) provide solid access control mechanisms for
> > > mtrace using mechanisms that are the most widely adopted form of security
> > > in ISPs
> > > and that this option of security in mtrace should not be dismissed just
> > > because
> > > it took us so long to bring the protocol in front of IESG review even if
> > > we agree
> > > that we should have better options beyond that.
> > 
> > The question is whether those options are in fact adequate. For the reasons
> > above I don't believe that.
> >
> > -Ekr
> 
> Cheers
>     Toerless
> 
> > 
> > 
> > >
> > > The other point was that better security options are something we should
> > > not
> > > invent as one-off protocol hack sinto mtrace (even if some mtrace none
> > > request/reply
> > > messages might be fun to define) but instead we should adopt solutions
> > > that are more
> > > likely in-line with existing network OAM security strategies. TLS
> > > connections,
> > > netconf/yang etc. pp. As i described in my email.
> > >
> > > Cheers
> > >     toerless
> > >
> > > > -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]
> 
> _______________________________________________
> MBONED mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mboned

-- 
---
[e-mail]