Subject: [straw] AD review of draft-ietf-straw-sip-traceroute-02

From: Richard Barnes <[email-masked]>
Date: Fri, 11 Apr 2014 13:44:30 -0400

I have reviewed this document in preparation for IETF LC.  It is clearly
written, but I have one technical concerns that I would like to address
before IETF LC.

I'm concerned that, as described, the mechanism will lead to confusion by
UAs.  How does a UA that initiates a loopback call know if it got the real
endpoint or just some intermediate B2BUA that happened to be the last one
to handle the INVITE?  Even if there is some indicator, it seems better to
have the B2BUAs only respond if there's some consent flag (e.g. Supported:
middlebox-answer).  Otherwise, you're requiring every existing UA to check
that it actually got all the way through.

Thanks,
--Richard

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 11 Apr 2014 14:22:46 -0400

On Apr 11, 2014, at 1:44 PM, Richard Barnes <[email-masked]> wrote:

> I have reviewed this document in preparation for IETF LC.  It is clearly written, but I have one technical concerns that I would like to address before IETF LC. 
> 
> I'm concerned that, as described, the mechanism will lead to confusion by UAs.  How does a UA that initiates a loopback call know if it got the real endpoint or just some intermediate B2BUA that happened to be the last one to handle the INVITE?

Section 3.2:
   ... When the ultimate target UAS answers a loopback-based INVITE
   with a Max-Forwards greater than or equal to 0, the Reason header
   would not be added to the response and the UAC will know the
   traceroute is complete.

> Even if there is some indicator, it seems better to have the B2BUAs only respond if there's some consent flag (e.g. Supported: middlebox-answer).  Otherwise, you're requiring every existing UA to check that it actually got all the way through. 

It's only requiring UAs that implement this doc to do so; and it's not a very hard thing for the UAC to check.

If a UAC just wants to do media-loopback to the final UAS, it would set Max-Forwars to 70 on its first attempt. Though it would still need to check the answer's Reason header field to verify some B2BUA hadn't answer it due to reaching the hop limit, but that's a good thing to check for. Ultimately the purpose of media-loopback is for testing+troubleshooting, so giving more info isn't a bad thing. :)

-hadriel

---

From: Richard Barnes <[email-masked]>
Date: Fri, 11 Apr 2014 15:29:31 -0400

On Fri, Apr 11, 2014 at 2:22 PM, Hadriel Kaplan
<[email-masked]>wrote:

> > I'm concerned that, as described, the mechanism will lead to confusion
> by UAs.  How does a UA that initiates a loopback call know if it got the
> real endpoint or just some intermediate B2BUA that happened to be the last
> one to handle the INVITE?
>
> Section 3.2:
> > Even if there is some indicator, it seems better to have the B2BUAs only
> respond if there's some consent flag (e.g. Supported: middlebox-answer).
>  Otherwise, you're requiring every existing UA to check that it actually
> got all the way through.
>
> If a UAC just wants to do media-loopback to the final UAS, it would set
> Max-Forwars to 70 on its first attempt. Though it would still need to check
> the answer's Reason header field to verify some B2BUA hadn't answer it due
> to reaching the hop limit, but that's a good thing to check for. Ultimately
> the purpose of media-loopback is for testing+troubleshooting, so giving
> more info isn't a bad thing. :)
>
>
If B2BUAs implement this spec as-is, then they'll see Max-Forwards: 0 and
answer the call -- they don't know whether this is part of a traceroute or
not.  So if a legacy UAC sends out a normal, non-traceroute, INVITE with
loopback, and it happens to time out at one of these B2BUAs, and the UAC
doesn't know to check for the Reason header for this value (because it's
legacy), then it ends up talking to the B2BUA instead of the UAS.

It seems like in order to resolve this, you need to either:
1. Require UACs that use loopback to check for Reason (and thus update RFC
6849)
2. Add some consent flag to the INVITE so that the B2BUA can tell
traceroutes from other INVITEs

--Richard

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 11 Apr 2014 16:22:53 -0400

On Apr 11, 2014, at 3:29 PM, Richard Barnes <[email-masked]> wrote:

> If B2BUAs implement this spec as-is, then they'll see Max-Forwards: 0 and answer the call -- they don't know whether this is part of a traceroute or not.  So if a legacy UAC sends out a normal, non-traceroute, INVITE with loopback, and it happens to time out at one of these B2BUAs, and the UAC doesn't know to check for the Reason header for this value (because it's legacy), then it ends up talking to the B2BUA instead of the UAS.

Good point. So that's another benefit then. B2BUAs solve call failure problems they didn't even know existed.
;)

Actually, getting back to serious mode, that could happen even without this draft. Max-Forward handling in B2BUAs has always been undefined behavior until the loopback draft, afaik.

> 1. Require UACs that use loopback to check for Reason (and thus update RFC 6849)

I'm fine with that.  Another option is to re-title this draft to be "Media-Loopback Usage in SIP" and add some text about that in general too.

> 2. Add some consent flag to the INVITE so that the B2BUA can tell traceroutes from other INVITEs

It won't help solve the problem you raised fully - it will help if all B2BUAs along the path implement this draft, but not if they just implement RFC 6849. Because they can still answer calls based on policy, and Max-Forwards=0 technically doesn't apply to them as a UAS unless they also implement the loopback draft.

-hadriel

---

From: Richard Barnes <[email-masked]>
Date: Fri, 11 Apr 2014 16:48:40 -0400

On Fri, Apr 11, 2014 at 4:22 PM, Hadriel Kaplan
<[email-masked]>wrote:

> > If B2BUAs implement this spec as-is, then they'll see Max-Forwards: 0
> and answer the call -- they don't know whether this is part of a traceroute
> or not.  So if a legacy UAC sends out a normal, non-traceroute, INVITE with
> Actually, getting back to serious mode, that could happen even without
> this draft. Max-Forward handling in B2BUAs has always been undefined
> behavior until the loopback draft, afaik.

Good point.  I did not have this in mind.

> I'm fine with that.  Another option is to re-title this draft to be
> "Media-Loopback Usage in SIP" and add some text about that in general too.
>
>
> It won't help solve the problem you raised fully - it will help if all
> B2BUAs along the path implement this draft, but not if they just implement
> RFC 6849. Because they can still answer calls based on policy, and
> Max-Forwards=0 technically doesn't apply to them as a UAS unless they also
> implement the loopback draft.
>

How about this in 3.2?

"""
The mechanism defined in this document could cause B2BUAs to send a 200
response to an INVITE that is not part of a traceroute.  In such cases, the
UAC would believe that it was exchanging media with the end UAS, when in
reality it is talking to an intermediate B2BUA.  The UAC can recognize this
situation by examining the Reason header.  It is RECOMMENDED that UACs
implementing RFC 6849 perform this check.  (Note that this problem is not
introduced by this document, since the behavior of B2BUAs with regard to
Max-Forwards has been undefined until the publication of
[I-D.ietf-straw-b2bua-loop-detection].)
"""