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

[Eric Rescorla <[e-mail]>]

Thanks. I am happy to meet in person in London if that would be useful

On Thu, Mar 15, 2018 at 7:51 AM, Hitoshi Asaeda <[e-mail]> wrote:

> Hi Warren, Eric, and folks,
>
> Kerry and I have been working on the security threat analysis initiated by
> Eric’s comments.
> Kerry is now doing double check for our thoughts and will post the story
> tomorrow, I guess.
>
> Sorry for the long delay, but please wait for a while.
>
> Thanks for your cooperation.
>
> Regards,
>
> Hitoshi
>
>
>
> > 2018/03/14 10:53, Hitoshi Asaeda <[e-mail]> wrote:
> >
> > Hi Warren,
> >
> > I have been working on the security threat analysis with Kerry but
> > not completed the documentation.
> > We will post our thoughts on the ml asap.
> > I’m sorry that I cannot attend this meeting at London locally, but
> > will try to attend via jabber.
> >
> > Regards,
> >
> > Hitoshi
> >
> >
> >> 2018/03/14 6:32, Warren Kumari <[e-mail]> wrote:
> >>
> >> It has been basically 2 weeks since the last update - can you let me
> >> know when I can expect progress? Will this be discussed in London?
> >>
> >> W
> >>
> >> On Wed, Feb 28, 2018 at 3:57 AM, Hitoshi Asaeda <[e-mail]>
> wrote:
> >>> Hi again,
> >>>
> >>>> 2018/02/27 8:56, Warren Kumari <[e-mail]> wrote:
> >>>>
> >>>> [ - IESG for clutter ]
> >>>>
> >>>> On Fri, Jan 26, 2018 at 4:58 PM, Eric Rescorla <[e-mail]> wrote:
> >>>>> Hi Toerless,
> >>>>>
> >>>>> I appreciate the solution thinking, but I don't want to overrotate
> on these
> >>>>> specific threats (though of course we must address them). My concern
> is that
> >>>>> if there are threats this obvious then we need a more complete threat
> >>>>> analysis. I.e., what are the avenues for attack with this protocol
> and then
> >>>>> what mechanisms prevent those things. The purpose of the security
> >>>>> considerations section is to make sure that that happens. Has
> someone done
> >>>>> that somewhere and it just didn't make it into the document?
> >>>>
> >>>>
> >>>> Toerless / authors,
> >>>>
> >>>> It has been around a month since this reply -- I'm hoping that the
> >>>> there has been more discussion and that I just fell off the thread and
> >>>> / or that my search foo has failed me.
> >>>>
> >>>> EKR makes good points (and holds a DISCUSS) - we need to figure out
> >>>> how to address them. Was there more discussions on the thread
> >>>> analysis? Clue bat appreciated.
> >>>
> >>> We may have to do some sort of security threat analysis and document
> the results,
> >>> along with possible remedies to address the existing threats.
> >>> We’ll seek comments in the ML after the authors agree on the idea.
> >>>
> >>> Best regards,
> >>>
> >>> Hitoshi
> >>>
> >>>
> >>>>
> >>>>>
> >>>>> -Ekr
> >>>>>
> >>>>>
> >>>>> On Thu, Jan 25, 2018 at 5:31 PM, Toerless Eckert <[e-mail]>
> wrote:
> >>>>>>
> >>>>>> On Thu, Jan 25, 2018 at 03:08:58PM -0800, Eric Rescorla wrote:
> >>>>>>>> My point B.1) explicitly disables lying about the requesting
> address,
> >>>>>>>> so
> >>>>>>>> it is explicitly meant to prohibit amplification attacks.
> >>>>>>>>
> >>>>>>>
> >>>>>>> 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.
> >>>>>>
> >>>>>>> (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]
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> I don't think the execution is relevant when it was obviously a bad
> >>>> idea in the first place.
> >>>> This is like putting rabid weasels in your pants, and later expressing
> >>>> regret at having chosen those particular rabid weasels and that pair
> >>>> of pants.
> >>>> ---maf
> >>>>
> >>>> _______________________________________________
> >>>> MBONED mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/mboned
> >>>
> >>
> >>
> >>
> >> --
> >> I don't think the execution is relevant when it was obviously a bad
> >> idea in the first place.
> >> This is like putting rabid weasels in your pants, and later expressing
> >> regret at having chosen those particular rabid weasels and that pair
> >> of pants.
> >>  ---maf
> >
>
>