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

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

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\))
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/x-MDzYhnUnrnS9mIWAlHVnQ9xqc
Subject: [secdir] SecDir Review of draft-ietf-straw-sip-traceroute-02
Precedence: list

Hi.

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.

Yoav

[secdir] SecDir Review of draft-ietf-straw-sip-tr… Yoav Nir