A Media-Based Traceroute Function for the Session Initiation Protocol (SIP)
draft-ietf-straw-sip-traceroute-03
Yes
(Alissa Cooper)
(Richard Barnes)
No Objection
(Adrian Farrel)
(Alia Atlas)
(Barry Leiba)
(Pete Resnick)
Note: This ballot was opened for revision 02 and is now closed.
Alissa Cooper Former IESG member
Yes
Yes
(for -02)
Unknown
Richard Barnes Former IESG member
Yes
Yes
(for -02)
Unknown
Spencer Dawkins Former IESG member
Yes
Yes
(2014-07-10 for -02)
Unknown
I'm a yes, when the issues already raised are sorted out. I'm very curious about Stephen's question on the interaction with SIP forking. Should this be mentioned in the document?
Adrian Farrel Former IESG member
No Objection
No Objection
(for -02)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -02)
Unknown
Barry Leiba Former IESG member
(was Discuss)
No Objection
No Objection
(2014-07-11)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(2014-07-07 for -02)
Unknown
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.
Brian Haberman Former IESG member
No Objection
No Objection
(2014-07-08 for -02)
Unknown
I will be interested in the answers to the questions raised by Kathleen and Benoit.
Jari Arkko Former IESG member
No Objection
No Objection
(2014-07-07 for -02)
Unknown
There has been no response to Meral's Gen-ART review. I think we should finish that discussion before approving the document.
Kathleen Moriarty Former IESG member
(was Discuss, No Objection)
No Objection
No Objection
(2014-09-26)
Unknown
Thanks for addressing my concerns on possible DOS attacks in the security considerations text.
Martin Stiemerling Former IESG member
No Objection
No Objection
(2014-07-09 for -02)
Unknown
In support of Kathleen's and Benoit's issues!
Pete Resnick Former IESG member
No Objection
No Objection
(for -02)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-07-08 for -02)
Unknown
- 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
Ted Lemon Former IESG member
No Objection
No Objection
(2014-07-10 for -02)
Unknown
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.