IETF Logo Mail Archive

Re: [MBONED] TSV Area Review of draft-ietf-mboned-mtrace-v2

Toerless Eckert <tte@cs.fau.de> Thu, 25 January 2018 23:05 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: mboned@ietfa.amsl.com
Delivered-To: mboned@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1F512EAD6; Thu, 25 Jan 2018 15:05:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.208
X-Spam-Level:
X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEY-wtZ6Bk93; Thu, 25 Jan 2018 15:05:48 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7C3C127735; Thu, 25 Jan 2018 15:05:47 -0800 (PST)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 2EFFD58C56E; Fri, 26 Jan 2018 00:05:43 +0100 (CET)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 15F3FB0D87C; Fri, 26 Jan 2018 00:05:42 +0100 (CET)
Date: Fri, 26 Jan 2018 00:05:42 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: "Brian Trammell (IETF)" <ietf@trammell.ch>
Cc: mboned@ietf.org, draft-ietf-mboned-mtrace-v2@ietf.org, tsv-art@ietf.org
Message-ID: <20180125230542.GC16477@faui40p.informatik.uni-erlangen.de>
References: <91243C66-4C6B-4A53-BB61-B6CE153FC31F@trammell.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <91243C66-4C6B-4A53-BB61-B6CE153FC31F@trammell.ch>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/wQqPVBxqyp0kd2s32KIE-9pWwM0>
Subject: Re: [MBONED] TSV Area Review of draft-ietf-mboned-mtrace-v2
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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, 25 Jan 2018 23:05:49 -0000

Brian:

Is there any standards, lightweight UDP based three way handshake transport proto stub 
one could steal, e.g.: just nonce based initiator spoofing prevention. Its kinda silly having to reinvent
this over and over again.

Cheers
    Toerless

On Wed, Jan 24, 2018 at 10:47:51AM +0100, Brian Trammell (IETF) wrote:
> However, I'm concerned about the potential for abuse of mtrace2. Specifically, replies are larger than queries, so the protocol can be used for amplification, and the protocol will send replies to a client address which is sent in cleartext without integrity protection, so the potential for redirection via spoofing exists.
> 
> The first, I think, could be addressed by requiring the initial query to be a near-maximum-size UDP packet, or at least larger than the reply packets.
> 
> The security concept in sections 9.1 and 9.2 seems to assume that client filtering at a network border is sufficient; however, this does not appear to address the case of inside an administrative domain spoofing its address. Section 9.5 acknowledges the potential of the protocol for amplification, but should provide concrete advice for rate limiting.
> 
> One question: this may be a moot question (I did not review mtrace v1), but it appears that mtrace2 is designed to share a port with mtrace1, and I don't see any version field in the messages. How is version transition handled by this protocol? Is it possible to run a mixed network with both mtrace versions and have the right thing (probably downgrade) happen, or is the assumption that mtrace version migration is a flag day? A related editorial suggestion: a list of changes from mtrace v1 to mtrace v2 in an appendix would be useful.
> 
> Cheers,
> 
> Brian



> _______________________________________________
> MBONED mailing list
> MBONED@ietf.org
> https://www.ietf.org/mailman/listinfo/mboned


-- 
---
tte@cs.fau.de

v2.23.0 | Report a Bug | By Email