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

[Hitoshi Asaeda <[e-mail]>]

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