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

[Hitoshi Asaeda <[e-mail]>]

Dear Eric,

Thank you for your comments.

We, authors, understand your thoughts.
However, as Toerless mentioned (thanks Toerless for explaining our thoughts), we believe this document already provides the basic security requirements for the mtrace specification itself.
We might say many of these security concerns would be discussed and addressed for IP multicast in general or with more specific model and mentioned in other documents.
But of course, we will clarify or explain in the revised draft if necessary and can see if you accept the explanation or not.

Thanks for your opinion.

Best regards,

Hitoshi


> 2018/01/20 4:31, 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]
> 
> 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 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, ...).
> 
> B.2) explicit permitting third-party mtrace only to trusted (OAM equipment) originators
> 
> The existing 9.2. text IMHO already says that you need to support ACLs
> to filter queries. Maybe add/replace with text being more specific about the
> intended deployment scenario:
> 
> | Beyond (or instead of) directly connected addresses, Mtrace queries MUST only be
> | processed through administratively established filtering from source IP addresses
> | that are known not to be spoofed and that are known to be authorized to receive the
> | conveyed (third party) multicast information. For example, professionally managed
> | networks typically have addresses ranges assigned to (subsets of) network OAM 
> | equipment that is also protected from address spoofing through filtering on the network
> | edge.
> 
>  [ _how_ to define that filtering is hopefully something we can leave off to
>    a future  companion document "yang model for mtrace", because some details
>    might be tricky:
>     - amend and/or superceed the "connected IP address" rule
>     - rule for "internal" operator addresses (e.g.: from BGP attributes)
>       vs. non-permitted "customer" addresses ]
> 
> 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 ?
> 
> 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/statement/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