A Media-Based Traceroute Function for the Session Initiation Protocol (SIP)
draft-ietf-straw-sip-traceroute-03

Thinking some more about this... I have some questions:
I'm not sure who can initiate this traceroute. Everybody?
Exactly like a normal traceroute, the output provides a potential attacker useful information on potential targets (this is not mentioned in the security considerations section)
As you wrote "Answering media-loopback calls in a B2BUA consumes resources on the B2BUA", so will it lead to an equivalent feature as "control plane policying" for B2BUA in the future?




OLD:
   A mechanism to perform
   media-loopback test sessions has been defined in [RFC6849], but it
   cannot be used to directly to test B2BUAs because typically the
   B2BUAs do not have an Address of Record (AoR) to be targeted, nor is
   it known a priori which B2BUAs will be crossed for any given
   session.
 
NEW (removed "to"): 
   A mechanism to perform
   media-loopback test sessions has been defined in [RFC6849], but it
   cannot be used directly to test B2BUAs because typically the
   B2BUAs do not have an Address of Record (AoR) to be targeted, nor is
   it known a priori which B2BUAs will be crossed for any given
   session.


OLD:
   The originating UAC can then generate another INVITE to the same
   target AoR with a Max-Forwards header field value of 1, which will
   reach the second SIP, and so on.

NEW:
   The originating UAC can then generate another INVITE to the same
   target AoR with a Max-Forwards header field value of 1, which will
   reach the second SIP next hop, and so on.

Or NEW (not too sure what's the best:
   The originating UAC can then generate another INVITE to the same
   target AoR with a Max-Forwards header field value of 1, which will
   reach the second SIP B2BUA, and so on.

I will be interested in the answers to the questions raised by Kathleen and Benoit.

There has been no response to Meral's Gen-ART review. I think we should finish that discussion before approving the document.

Thanks for addressing my concerns on possible DOS attacks in the security considerations text.

In support of Kathleen's and Benoit's issues!

- I support Kathleen's discuss. The potential DoS vector here
ought be described as should mitigations and maybe it ought
even be limited e.g. via defaults on e.g. the duration for
which media is sent.

- Almost certainly not worth a mention bnt this could be a
nice covert channel if I had a UAS or B2BUA under my control.

- Can't SIP requests be forked? What happens if two B2BUAs
answer the INVITE with media? 

- I guess different B2BUAs or different numbers of such could
be involved each time you increment the counter, e.g. because
of load balancing or odd routing or call forwarding etc. I
don't think that's called out explicitly but I guess that's
probably fine and you just accept that traceroute can throw
up oddities like that.

- (Almost a discuss) Why "SDP based on [RFC6849]"? That
seems very imprecise, esp if there is any ambiguity in
6849 (which I don't know).

- Who hangs up the test call? Is it ok for the UAC to
have the previous one still active when incrementing
the counter and starting the next one?

- The secdir review [1] raised some issues but got no
response at all.

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg04875.html

I appreciate the intent of the security considerations section, but isn't this mechanism somewhat useless of the advice implicit here is followed?   It seems that the policy you _want_ is for any intermediary that would carry the ordinary call to also be willing to do the loopback, and that this eliminates the possibility of DOS-related misuse, since presumably an actual call would consume more resources than the traceroute attempt will.