Last Call Review of draft-ietf-straw-sip-traceroute-02
review-ietf-straw-sip-traceroute-02-secdir-lc-nir-2014-07-03-00

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