[MBONED] Eric Rescorla's Discuss on draft-ietf-mboned-mtrace-v2-22: (with DISCUSS and COMMENT)
Eric Rescorla <ekr@rtfm.com> Thu, 18 January 2018 15:34 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: mboned@ietf.org
Delivered-To: mboned@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9B1126E3A; Thu, 18 Jan 2018 07:34:59 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mboned-mtrace-v2@ietf.org, Leonard Giuliano <lenny@juniper.net>, mboned-chairs@ietf.org, lenny@juniper.net, mboned@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.69.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151628969901.2325.7724014542086691903.idtracker@ietfa.amsl.com>
Date: Thu, 18 Jan 2018 07:34:59 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/y5dx3X4NRFEJdi6OJQWnVGbNDbU>
Subject: [MBONED] Eric Rescorla's Discuss on draft-ietf-mboned-mtrace-v2-22: (with DISCUSS and COMMENT)
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jan 2018 15:34:59 -0000
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.
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Kerry Meyer
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Kerry Meyer
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Warren Kumari
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- [MBONED] Eric Rescorla's Discuss on draft-ietf-mb… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Toerless Eckert
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Toerless Eckert
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Toerless Eckert
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Toerless Eckert
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Warren Kumari
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Warren Kumari
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Kerry Meyer
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Kerry Meyer
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Kerry Meyer
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Eric Rescorla
- Re: [MBONED] Eric Rescorla's Discuss on draft-iet… Hitoshi Asaeda