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

[Hitoshi Asaeda <[e-mail]>]

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
>