[secdir] SecDir Review of draft-ietf-straw-sip-traceroute-02

Yoav Nir <ynir.ietf@gmail.com> Sun, 29 June 2014 13:23 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id C2F661A04B7; Sun, 29 Jun 2014 06:23:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nsxIg7tAYKgL; Sun, 29 Jun 2014 06:23:01 -0700 (PDT)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946021A04AE; Sun, 29 Jun 2014 06:23:00 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id hi2so4817327wib.11 for <multiple recipients>; Sun, 29 Jun 2014 06:22:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=qF+ckbPIxAIU1YyvYIroFpz+hvsn2ZR1kiHQJnhjdVA=; b=ZTbYurboYB3C0L19sjD4ENM0M/8sFq1bsfRaz+BQL6gbHWZWENGVx7exwqlSbup4GD JHE2aXIbPzTyoLd1w93GUvTXKiL4QwkoxF95pd+L7hWo6GlkUOK2jTNd20mdjA/+x3uN 9KnRLwd4KK52OtMwbARzwCqLU+GIq2c1BKzsgPlmHVj6u9yATtl+AwHJyZ477llR2uPq kBuHfcnUYtnAPFwg27VMrd5TZSOrETb1QkmqhsJ4DDaeQu3a0CkXB10NfOnJUcwbQr7V ewzf40S+XMZW1ynhXNk57i6jVX/STU0sz/R/Tr6mf+X+zYq50uxX1NDBbm5dYoc53FS+ fEag==
X-Received: by with SMTP id hb3mr23103112wib.8.1404048179225; Sun, 29 Jun 2014 06:22:59 -0700 (PDT)
Received: from [] (dyn32-131.checkpoint.com. []) by mx.google.com with ESMTPSA id m3sm34513615wjr.49.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Jun 2014 06:22:58 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Message-Id: <C49D446F-F9B6-47E3-8A93-A861E2DA44AC@gmail.com>
Date: Sun, 29 Jun 2014 16:22:55 +0300
To: "<iesg@ietf.org> IESG" <iesg@ietf.org>, "<secdir@ietf.org>" <secdir@ietf.org>, draft-ietf-straw-sip-traceroute.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/x-MDzYhnUnrnS9mIWAlHVnQ9xqc
Subject: [secdir] SecDir Review of draft-ietf-straw-sip-traceroute-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Jun 2014 13:23:03 -0000


I have reviewed this document as part of the security directorate’s ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Short version: the document is ready with a few changes needed.

The document extends the media-loopback mechanism, described in RFC 6849. That mechanism is used to monitor the performance of media delivery along a path by having the target reflect back the a media stream. So it’s like ECHO, only for media. This document extends that mechanism by allowing the monitoring to be performed with the hops along the way (proxies and B2BUAs) rather than only end-to-end. This allows for better trouble-shooting and helps find the problematic hop. It uses a traceroute-like mechanism with a decreasing TTL, except here it’s the Max-Forwards header field that gets decremented at each hop. When max-forwards reaches zero, the B2BUA replies with a 200 message, “answering the call”, and media loopback tests can be used.

This document depends on draft-ietf-straw-b2bua-loop-detection (now in RFC editor’s queue). B2BUAs that do not support the latter specification, will not decrement the max-forwards fields, and thus will not take part in the protocol. In such a case, the path will appear to have fewer B2BUAs than it actually has.

The security considerations section is very short, and only mentions the possibility of resource exhaustion because of all those calls doing media-loopback, without using the term “denial of service”. IMO most of the security considerations of RFC 6849 apply here as well (with the exception of the UA indicating to the human that a loopback session is happening - B2BUAs don’t have humans), so they should be repeated here at least by reference (as RFC 6849 itself references 3264 and 3550).  

The section says "B2BUAs should have some means of controlling who can make such test calls, how many concurrent calls can be established and maintained, and for how long.”  I think a document like this should offer something more about what these “some means” are. It’s possible to require authentication of the UA doing the testing to the B2BUA being tested. This aligns with the recommendation in RFC 6849, but I don’t know whether or not authentication to B2BUAs is feasible in the real world.